1 / 24

Analysis for Evolution

セッション 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 適用先のドキュメントに記述に対応する要素がない、 対応する要素はあるが他の記述が優先される 不要 な記述の問題点：

illana-combs
Télécharger la présentation

Analysis for Evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. セッションK Analysis forEvolution 阪大 井上研 神田 哲也・石尾 隆

  2. 論文K1 Automated Analysis of CSS Rules to Support Style Maintenance Ali Mesbah and ShabnamMirshokraie

  3. 概要 • Cascading Style Sheets(CSS)中の不要な記述を特定する • 不要な記述：CSS適用先のドキュメントに記述に対応する要素がない、対応する要素はあるが他の記述が優先される • 不要な記述の問題点： • 通信路やメモリの容量圧迫 • ブラウザへの負荷 • 可読性の低下 • これまでのCSSに関する解析は静的解析が主 • 精度もあまりよくない • 動的解析を使う

  4. CSSの適用例 • CSS:HTML要素の表示に関する指示 • 継承、波及、セレクタの詳細度など数々の特徴 • Document Object Model（DOM） • 実行時のHTMLを表す標準的なオブジェクトモデル • CSSの適用先 DOM <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> CSS ↓セレクタ　　　　↓プロパティ #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> 例：赤のプロパティのみが右の2つのDOMで有効になっている

  5. CSSとDOMの関係 • Matched Selector：CSSセレクタに対応するDOM要素が存在する • Unmatched：対応するDOM要素が存在しないので不要 • Effective Selector：CSSセレクタが実際に適用されるDOM要素が存在する • Ineffective：ほかのセレクタの優先度が高いため適用されないので不要 • 個々のプロパティについても同様に考えることができる • Unused = Unmatched+ Ineffective • Defined Class Values：DOM要素のクラスに対応するCSSセレクタが存在する • Undefined：JavaScriptなど他の目的で利用される場合を除き不要

  6. 評価実験 • 対象：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

  7. 論文K2 Graph-Based Analysis andPrediction for Software Evolution Pamela Bhattacharya, MariosIliofotou, IulianNeamtiu and MichalisFaloutsos

  8. 論文の概要 • 長期間開発されているシステムを対象として，グラフに関するメトリクスの有効性を調査した • 調査対象 • C/C++ (10システム): Firefox, Blender, VLC, MySQL, Samba, Bind, Sendmail, OpenSSH, SQLite, Vsftpd • Java (1システム): Eclipse • 9年以上開発が続いているもの • 調査方法 • 関数のコールグラフ，モジュール間の参照グラフを使って３つの調査 • 開発者間の関係グラフ2種を使って１つの調査 • 調査ごとに，使用したグラフ・メトリクス・システムは異なることに注意 • グラフに関するメトリクスを多数のバージョンについて調査したことが新規性

  9. 論文で報告されている内容 • グラフに関するメトリクスの用途を４つ示した • 関数のコールグラフに関するメトリクスは，ソフトウェアが違っても似たような値の変動をする(4章) • メトリクスの突然の変化は，システム構造の大きな変化に対応する • 関数・モジュールは，多くの関数・モジュールから参照されているものほど，そこで発生したバグの Severity が高い (5章) • モジュール性を表現する ModularityRatioメトリクスが高いほど，そのモジュールの Maintenance Effort は小さい (6章) • 開発者間でのバグ対応の協力関係グラフ（１年単位）が変化するほど，そのシステムはバグが多い (7章)

  10. 関数・モジュールに関するグラフ 一般的に使われている定義と同様 • 関数のコールグラフ • 関数をノードとする有向グラフ • 関数 f1, f2 について，f1 が f2 を呼び出しているとき辺 f1  f2 を持つ • Dynamic Dispatch は すべての可能性を考慮 • モジュール間の参照関グラフ • モジュールをノードとする有向グラフ • モジュール A, B について，A の関数が B の関数を呼び出している，もしくは， A の関数が B の変数にアクセスしているとき，辺 AB を持つ

  11. グラフに対するメトリクス ソフトウェアごとにあまり違いはない（進化には共通性がある）． 値の大きな変化から，構造の変化が検知できると述べている． • Average clustering coefficient • ある頂点 u に接続されている頂点が，互いに接続されている確率（密結合なグラフで値が高い） • Graph diameter • グラフの任意の２頂点間での最短経路長の最大値 • Assortativity • 各辺が接続している２頂点が同じぐらいの次数を持っているかどうかを判定する値 • Number of nodes in cycles • グラフ内で，有向辺で循環的に接続された頂点の数

  12. 頂点に対するメトリクス • Node Rank • Page Rank 系メトリクス．多数のノードから直接・間接的に参照されているノードほど値が高い • Bug Severity と相関あり（値が高いノードほど，Bug Severity が高い） • Modularity Ratio • モジュール間よりもモジュール内の呼び出し・変数アクセスが多いほど値が高い • 値が高いノードほど，Maintenance Effort （リリースごとの「コミット回数÷編集行数」）が低い 収束するまで反復計算. 総和が 1 になるよう正規化

  13. 開発者間のグラフに関する調査 • 開発者を頂点とするグラフ2種を定義 • 同じチームで仕事をしていると生産性が高くなると仮定 • グラフの変化量と，バグの個数を調べた • Bug-tossing collaboration: 開発者Aが担当していたバグが（Aには解決できなかったので）開発者 B に割り当てられたとき A  B • File-based collaboration: 開発者 A と B が同じファイルを編集していれば A—B (無向辺) • 1年ずつの活動に対して作った Bug-tossing グラフのEdit distance (変化量)が大きいほど，バグ数が多い • File-based collaboration では相関が認められなかった

  14. 論文K3 Integrated Impact Analysis for Managing Software Changes MalconGethers, BogdanDit, HuzefaKagdi, Denys Poshyvanyk

  15. 論文の概要 • 「追加情報があれば使う」 Impact Analysis の提案 本論文でのImpact Analysis とは： Change Request に対して，変更する必要があるすべてのメソッドを特定すること Impact Analysis: CR  a set of methods • 著者らが従来行ってきた FeatureLocation は，ある機能に対応するソースコード位置を特定する技術． • Feature Location した範囲を基点に Impact Analysis を実行する，と別論文で述べられている • 要素技術としては，これまでの Feature Location 技術を少し改変したもの • 再テストが必要な範囲を特定する技術ではない • 単純な IR 手法と比較して，追加情報による出力の改善度合いを示した

  16. Impact Analysis の計算手順 (1/2) • 基本形 (IRCR)： LSI を使用した文書類似度の計算 • メソッド単位を文書として tf-idfの単語出現頻度行列を作成 • 予約語除去，長い識別子の単語への分解，動詞の原型への変換 • LSI を適用 • Change Request を文書とみなした場合の，各メソッドとのコサイン尺度を計算し，類似度の高い順でランキングを作る • 実行履歴が存在する場合 (IRCRDynCR) • Change Request に書かれている機能実行手順を使ってプログラムを実行し，実行されたメソッド情報を記録 • IRCRのランキングから，実行されてないメソッドを取り除く

  17. Impact Analysis の計算手順 (2/2) • バージョン管理システムに履歴が存在しており，かつ，１つのメソッドが「正解」と判明している場合（IRCRHistseed） • 編集内容が同時にコミットされているメソッドを Itemset Mining で探索 • あるメソッドが編集されたら他のメソッドも編集されている，という Association Rules へと変換 • 開発者がどうにかして（Feature Locationなどで）選んだ「正解」メソッドを基点に，適用可能な Association Rules の強い順にメソッドをランキング • 同時に変更される可能性が高いものほど上位 • IRCRのランキング上位 N/2 件とHistseedの上位 N/2 件を足して N個のランキングを作る • N個に達するまで，２つのランキングから交互に追加候補を取り込む • ３種の組み合わせ IRCRDynCRHistseed • IRCRHistseed の最後のステップで使うランキングを IRCRからIRCRDynCRに変更

  18. 評価実験 • ４つの 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 への影響が不明瞭

  19. 論文K4 Detecting and Visualizing Inter-worksheet Smells in Spreadsheets FelienneHermans, Martin Pinzger and Arie van Deursen

  20. 論文の概要 • 業務に使う表計算のスプレッドシートから，まずい設計（Smells）を見つける • 数式によるデータの参照を，ソースコードの依存関係に見立てて， Code Smells の定義を持ち込んだ • Smells の条件をメトリクスで定義した • ICSE2011 で提案したデータフロー可視化手法に，Smells の情報を追加して提供するツールを構築した • ケーススタディによって，Smells の指摘が利用者に有用であることを示した

  21. 用語 • スプレッドシート • 表計算ソフトで保存されるファイル単位．複数のワークシートを含む． • ワークシート • 行・列に並んだセルによって構成されるシート． • セル • 「数式」を使って他のセルの値から数値を計算することができる． • Connection • セルの組 (A, B) で表現．セル A が， B の内容を参照する式を持つことを意味する． • 主にこれを使ってメトリクスを定義．

  22. 定義した Smells • Inappropriate Intimacy • スプレッドシート内部で，ワークシート間の Connection が多いようなワークシートの組がある． • Feature Envy • ある１つのセルが，他のワークシートの多数のセルを参照している． • Middle Man • ワークシート内で，セルの値を “=” によって中継している経路が多い． • Shotgun Surgery • Formulas: 1つのワークシートの内容が，他のワークシートの多数のセルに参照されている． • Worksheets: 1つのワークシートの内容が，多数のワークシートに参照されている．

  23. メトリクスによる Smells の検出 • 各 Smells は，問題となる参照関係などが「多い」ことが条件 • カウント条件をそれぞれ定義し，メトリクス値でソートしたときの上位 10～30% を Smells 検出の閾値とする • メトリクスはセル単位，ワークシート単位で定義．検出結果はスプレッドシート単位で集計． • Euses corpus からの検出結果(上位10%の場合) • Feature Envy (5.8%) • Inappropriate Intimacy (4.2%) • Middle Man (4.0%) • Shotgun Surgery (1.5%)

  24. ケーススタディ • 方法 • 資産管理会社のアナリストが使っているプレッドシート10個 • うち7個から検出されたSmellsを利用者に確認してもらった • 結果： • ワークシート間の参照関係が複雑である (Feature Envy などが多い) のは，作成した人にメンタルモデルがないから • ワークシート間の関係が整理されていない • あとから見て「なぜこうしたのか」思い出せない・記録していない • Smells には対応を行ったほうがよいという回答が得られた • Smells の自動検出が，きちんと問題点を指摘している • Feature Envy だけは，「データ保存用シート」「計算用シート」という２つの役割になっている場合があった

More Related