Aluminum: Principled Scenario Exploration through Minimalit

Presentation on theme: "Aluminum: Principled Scenario Exploration through Minimalit"— Presentation transcript:

Aluminum: Principled Scenario Exploration through Minimality

酒井 政裕

2013-07-09ICSE2013 勉強会

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

の例

F1

abstract 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 を実装

機能GenerateMin極小なシナリオの生成・列挙(関係からタプルを一つでも取り除くと、制約を満たさなくなる)Augmentシナリオを、関係にタプルを追加することでユーザが拡張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 UnrealizableScenario-Based Specifications

サーベイ担当: 遠藤侑介

Shahar MaozSchool of Computer ScienceTel Aviv University, Israel

Yaniv

Sa’ar

Dept. of Computer Science

Weizmann Institute of Science, Israel

シーケンス図からコントローラを合成する問題点：デバッグがつらい合成器「充足不可能な制約があって合成できないよ」設計者「えー。どこを直せと。合成器のバグじゃないの」

背景

: Play-out

panel

cashier

insertCoin()

incCoins()

合成

cashier

の

プログラム

p

anel

の

プログラム

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

提案: 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

手続き的な推定アルゴリズム

（大抵ハードコーディング）

手続き的なアルゴリズムの弱点

わかりにくい出力FSMの特徴が読み取れないいじりにくい「こんな遷移を出したい／消したい」「２つのアルゴリズムをマージしたい」比較すんのツラい並べてもわからん

※ Fig. 3

FSMの性質を宣言的に書けばそのとおりのFSMが出てくるツールを作りました

こういうパターンを並べれば、お望みの

FSMが出てくる

わかりやすい特徴がそのまま書いてあるいじりやすい追加・削除・マージ≒ 宣言を足したり引いたり比較しやすい並べて見比べればいい（おまけ）性能もすんげく上がりました

※ 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

）

…

労力に見合う効果はある