Aluminum: Principled Scenario Exploration through Minimality

酒井 政裕2013-07-09

ICSE2013 勉強会

The background image is from http://images-of-elements.com/. The image is licensed under a Creative Commons Attribution 3.0 Unported License.

F1

by Tim Nelson, Salman Saghafi, Daniel J. Dougherty,Kathi Fisler, Shriram Krishnamurthi @ ICSE 2013

背景• 背景

– 高レベルの仕様記述に対して「シナリオ」 (= 具体例 )を探索・生成する Alloy などのツール

– シナリオの利点• システム設計者が、その設計の帰結、見落としていた制約、

代替的なデザインなどを検討するのを助ける• 具体的なので分かりやすく、現実に対応させやすい。• 論理学等に詳しくない、ドメインの専門家にも理解可能

• 課題– 複数あるシナリオから、どんなシナリオをどんな順で

提示するべきか？– 小さいシナリオはしばしば病的で、微妙な問題を明ら

かにすることが多い– ⇒ 小さいシナリオから提示するように出来ないか？

F1

Alloy の例 F1abstract sig Subject {}sig Student extends Subject {}sig Professor extends Subject {}sig Class { TAs: set Student, instructor: one Professor}sig Assignment { forClass: one Class, submittedBy: some Student}pred PolicyAllowsGrading(s: Subject, a: Assignment) { s in a.forClass.TAs or s in a.forClass.instructor}pred WhoCanGradeAssignments() { some s : Subject | some a: Assignment | PolicyAllowsGrading[s, a]}run WhoCanGradeAssignments for 3 コードと図は Aluminum: Principled Scenario Exploration through

Minimality (by Tim Nelson, Salman Saghafi, Daniel J. Dougherty, Kathi Fisler, Shriram Krishnamurthi) より抜粋

F1複数シナリオの列挙

図は Aluminum: Principled Scenario Exploration through Minimality (by Tim Nelson, Salman Saghafi, Daniel J. Dougherty, Kathi Fisler, Shriram Krishnamurthi) より抜粋

…

Next

Next

Next

Alloy を変更し Aluminum を実装

機能1. GenerateMin

– 極小なシナリオの生成・列挙( 関係からタプルを一つでも取り除くと、制約を満たさなくなる )

2. Augment– シナリオを、関係にタプルを追

加することでユーザが拡張3. ConsistentTuples

– シナリオに対し、関係に追加可能なタプルを計算

F1

シナリオ探索のスタートポイント余計なものを含まない、シナリオの本質に注目！

対話的探索！

「制約を追加して再探索」というコンテキストスイッチを減らす

F1

図は Aluminum: Principled Scenario Exploration through Minimality (by Tim Nelson, Salman Saghafi, Daniel J. Dougherty, Kathi Fisler, Shriram Krishnamurthi) より抜粋

Alloy

Aluminum

Next Next

Next Next

列挙の比較

• アルゴリズムは素直– SAT レベルでの制約の順次追加による極小化など– ただし、 Symmetry-Breaking は極小化との相互作用の

問題から、 Alloy(KodKod) と別のヒューリスティクスを採用

• 実験を通じた観察– Alloy は特定の極小シナリオの上位のシナリオばかり

を列挙し、それ以外を数百回以上も出さないことが多い

– それまでにユーザが探索をやめてしまい、重要・危険なシナリオを見逃す危険性

– Aluminum はシナリオ空間の本質をユーザに早く見せる

• 性能への影響はあまりなし

F1

Counter Play-Out:Executing Unrealizable

Scenario-Based Specifications

サーベイ担当 : 遠藤侑介

Shahar MaozSchool of Computer Science

Tel Aviv University, Israel

Yaniv Sa’arDept. of Computer Science

Weizmann Institute of Science, Israel

• シーケンス図からコントローラを合成する

• 問題点：デバッグがつらい– 合成器「充足不可能な制約があって合成できないよ」– 設計者「えー。どこを直せと。合成器のバグじゃない

の」

背景 : Play-out

panel cashier

insertCoin()

incCoins()合成

cashier のプログラム

panel のプログラム

自動販売機のシーケンス図

提案 : Counter Play-out• 合成できない場合、代わりに「ユーザ」を合成する

– 合成された「ユーザ」は意地悪： システムがどうしようと、最終的に制約違反してしまうように振る舞う

– 合成器「ならお前がシステムやれよ。俺がユーザやるから」

– 設計者「……なるほど実現できない。すみませんでした」

insertCoin()

incCoins()

意地悪なユーザを

シミュレートする

プログラム

panel cashier

合成

貢献の概要• 「意地悪なユーザ」の合成方法

– アルゴリズム自体はコントローラの合成とほぼ同じ

• BDD ベースの symbolic algorithm

– 解く制約が反転している• 実際に実装し、試してみた

– PlayGo: シナリオベース仕様の Eclipse IDE– 小規模～中規模な例を 15 個ほど作ってみた

• 論文には自動販売機のみ（シーケンス図 5 つ）• 状態数や合成にかかる時間の簡単な評価はあり• ユーザスタディ（デバッグ時間とか）は言及なし

F3. Unifying FSM-Inference Algorithms throughDeclarative Specification

担当：今井健男（ T芝）

by Ivan Beschastnikh , Yuriy Brun , Jenny Abrahamson , Michael D. Ernst , and Arvind Krishnamurthy

実行ログから状態遷移モデル（ FSM）を推定したい

※ Fig. 2

※ Fig. 2

実行ログから状態遷移モデル（ FSM）を推定したい

※ Fig. 3

手続き的な推定アルゴリズム（大抵ハードコーディング）

手続き的なアルゴリズムの弱点1. わかりにくい

出力 FSM の特徴が読み取れない

2. いじりにくい 「こんな遷移を出し

たい／消したい」 「２つのアルゴリズ

ムをマージしたい」

3. 比較すんのツラい 並べてもわからん

※ Fig. 3

FSM の性質を宣言的に書けばそのとおりの FSM が出てくるツールを作りました こういうパターンを並べれば、お

望みの FSM が出てくる

1. わかりやすい 特徴がそのまま書いてある

2. いじりやすい 追加・削除・マージ

≒ 宣言を足したり引いたり

3. 比較しやすい 並べて見比べればいい

4. （おまけ）性能もすんげく上がりました

※ Fig. 13

F4. What Good Are Strong Specifications?

by Nadia Polikarpova,Carlo A. Furia,Yu Pei,and Bertrand Meyer

担当：今井健男（ T芝）

強い形式仕様 vs. お手軽形式仕様

≒ completeみんないやがる

書くの大変

≒ incomplete, partialみんなに人気

Design by Contract (DbC) 実行可能な仕様だけ

Test-Driven Development(TDD) テストケース＝形式仕様

(strong) (lightweight)

強い仕様を書く価値はあるのか？をエンピリカルに分析・評価（＋「強い仕様 /契約」の書き方の提案）

お手軽仕様（ DbC）挿入後の要素数は

2 リストの要素数の合計

指定位置は挿入前後で同じ

強い仕様（Model-Based Contract, MBC）

ただし sequence, front, tail, ‘+’ は別に与える

※ Fig. 1 より抜粋

※ Fig. 2 より抜粋

「線形リストの指定位置の後ろに、別のリストを挿入」の事後条件

分析・評価してみた 21種の Eiffel コードに対する DbC と MBC で比較 総テストケース 8700万個、総テスト時間 1680時

間（！）分のテスト生成、バグの見つかり方を比較

結果（の一部をざっくりと）： MBC の方が、バグが 2倍以上見つかった（ 103 vs. 48）

記述量（仕様記述の行数 / コード行数）もほぼ 2倍程度（ 0.46 vs. 0.2）

…労力に見合う効果はある