k - qwik.jp

1
セッションK
ANALYSIS
FOR EVOLUTION
阪大井上研
神田哲也・石尾隆
2
論文K1
AUTOMATED ANALYSIS OF CSS
RULES TO SUPPORT STYLE
MAINTENANCE
Ali Mesbah and Shabnam Mirshokraie
概要
• Cascading Style Sheets(CSS)中の不要な記述を特定する
• 不要な記述：CSS適用先のドキュメントに記述に対応する要素がない、
対応する要素はあるが他の記述が優先される
• 不要な記述の問題点：
• 通信路やメモリの容量圧迫
• ブラウザへの負荷
• 可読性の低下
• これまでのCSSに関する解析は静的解析が主
• 精度もあまりよくない
• 動的解析を使う
4
CSSの適用例
• CSS:HTML要素の表示に関する指示
• 継承、波及、セレクタの詳細度など数々の特徴
• Document Object Model（DOM）
• 実行時のHTMLを表す標準的な
オブジェクトモデル
• CSSの適用先
↓セレクタ
↓プロパティ
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; }
例：赤のプロパティのみが右の2つのDOMで有効になっている
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>
<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>
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 AND
PREDICTION FOR SOFTWARE
EVOLUTION
Pamela Bhattacharya, Marios Iliofotou,
Iulian Neamtiu and Michalis Faloutsos
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 系メトリクス．多数のノードから直接・間接的に参照されて
いるノードほど値が高い
収束するまで反復計算.
総和が 1 になるよう正規化
• Bug Severity と相関あり（値が高いノードほど，Bug Severity が高い）
• Modularity Ratio
• モジュール間よりもモジュール内の呼び出し・変数アクセスが多いほど
値が高い
• 値が高いノードほど，Maintenance Effort （リリースごとの「コミット回数
÷編集行数」）が低い
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
Malcon Gethers, Bogdan Dit,
Huzefa Kagdi, Denys Poshyvanyk
15
論文の概要
• 「追加情報があれば使う」 Impact Analysis の提案
本論文でのImpact Analysis とは： Change Request に対し
て，変更する必要があるすべてのメソッドを特定すること
Impact Analysis: CR  a set of methods
• 著者らが従来行ってきた Feature Location は，ある機能に対応するソース
コード位置を特定する技術．
• Feature Location した範囲を基点に Impact Analysis を実行する，と別論文で述
べられている
• 要素技術としては，これまでの Feature Location 技術を少し改変したもの
• 再テストが必要な範囲を特定する技術ではない
• 単純な IR 手法と比較して，追加情報による出力の改善度合いを示
した
16
Impact Analysis の計算手順 (1/2)
• 基本形 (IRCR)： LSI を使用した文書類似度の計算
1. メソッド単位を文書として tf-idf の単語出現頻度行列を作成
•
2.
3.
予約語除去，長い識別子の単語への分解，動詞の原型への変換
LSI を適用
Change Request を文書とみなした場合の，各メソッドとのコサイン尺
度を計算し，類似度の高い順でランキングを作る
• 実行履歴が存在する場合 (IRCRDynCR)
1. Change Request に書かれている機能実行手順を使ってプログラム
を実行し，実行されたメソッド情報を記録
2. IRCR のランキングから，実行されてないメソッドを取り除く
17
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 に変更
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
Felienne Hermans, 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 だけは，「データ保存用シート」「計算用シート」という２つの役割
になっている場合があった

Download Report