1 / 20

Aluminum: Principled Scenario Exploration through Minimality

F1. Aluminum: Principled Scenario Exploration through Minimality. by Tim Nelson, Salman Saghafi, Daniel J. Dougherty, Kathi Fisler, Shriram Krishnamurthi @ ICSE 2013. 酒井 政裕 2013-07-09 ICSE2013 勉強会. The background image is from http://images-of-elements.com/.

zeph-flowers
Download Presentation

Aluminum: Principled Scenario Exploration through Minimality

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. F1 Aluminum: Principled Scenario Exploration through Minimality by Tim Nelson, Salman Saghafi, Daniel J. Dougherty,Kathi Fisler, Shriram Krishnamurthi @ ICSE 2013 酒井 政裕 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.

  2. F1 背景 • 背景 • 高レベルの仕様記述に対して「シナリオ」(=具体例)を探索・生成するAlloyなどのツール • シナリオの利点 • システム設計者が、その設計の帰結、見落としていた制約、代替的なデザインなどを検討するのを助ける • 具体的なので分かりやすく、現実に対応させやすい。 • 論理学等に詳しくない、ドメインの専門家にも理解可能 • 課題 • 複数あるシナリオから、どんなシナリオをどんな順で提示するべきか？ • 小さいシナリオはしばしば病的で、微妙な問題を明らかにすることが多い • ⇒ 小さいシナリオから提示するように出来ないか？

  3. F1 Alloyの例 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) より抜粋

  4. F1 複数シナリオの列挙 Next Next Next … 図は Aluminum: Principled Scenario Exploration through Minimality (by Tim Nelson, Salman Saghafi, Daniel J. Dougherty, Kathi Fisler, Shriram Krishnamurthi) より抜粋

  5. F1 Alloy を変更し Aluminum を実装 機能 • GenerateMin • 極小なシナリオの生成・列挙(関係からタプルを一つでも取り除くと、制約を満たさなくなる) • Augment • シナリオを、関係にタプルを追加することでユーザが拡張 • ConsistentTuples • シナリオに対し、関係に追加可能なタプルを計算 シナリオ探索の スタートポイント 余計なものを含まない、シナリオの本質に注目！ 対話的探索！ 「制約を追加して再探索」という コンテキストスイッチを減らす

  6. Alloy F1 列挙の比較 Next Next Aluminum Next Next 図は Aluminum: Principled Scenario Exploration through Minimality (by Tim Nelson, Salman Saghafi, Daniel J. Dougherty, Kathi Fisler, Shriram Krishnamurthi) より抜粋

  7. F1 • アルゴリズムは素直 • SATレベルでの制約の順次追加による極小化など • ただし、Symmetry-Breakingは極小化との相互作用の問題から、Alloy(KodKod)と別のヒューリスティクスを採用 • 実験を通じた観察 • Alloyは特定の極小シナリオの上位のシナリオばかりを列挙し、それ以外を数百回以上も出さないことが多い • それまでにユーザが探索をやめてしまい、重要・危険なシナリオを見逃す危険性 • Aluminumはシナリオ空間の本質をユーザに早く見せる • 性能への影響はあまりなし

  8. Counter Play-Out:Executing UnrealizableScenario-Based Specifications サーベイ担当: 遠藤侑介 ShaharMaoz School of Computer Science Tel Aviv University, Israel YanivSa’ar Dept. of Computer Science Weizmann Institute of Science, Israel

  9. 背景: Play-out panel cashier panel の プログラム insertCoin() cashier の プログラム 合成 incCoins() 自動販売機のシーケンス図 • シーケンス図からコントローラを合成する • 問題点：デバッグがつらい • 合成器「充足不可能な制約があって合成できないよ」 • 設計者「えー。どこを直せと。合成器のバグじゃないの」

  10. 提案: Counter Play-out panel cashier 意地悪なユーザを シミュレートする プログラム insertCoin() 合成 incCoins() • 合成できない場合、代わりに「ユーザ」を合成する • 合成された「ユーザ」は意地悪： システムがどうしようと、最終的に制約違反してしまうように振る舞う • 合成器「ならお前がシステムやれよ。俺がユーザやるから」 • 設計者「……なるほど実現できない。すみませんでした」

  11. 貢献の概要 • 「意地悪なユーザ」の合成方法 • アルゴリズム自体はコントローラの合成とほぼ同じ • BDD ベースの symbolic algorithm • 解く制約が反転している • 実際に実装し、試してみた • PlayGo: シナリオベース仕様の Eclipse IDE • 小規模～中規模な例を 15 個ほど作ってみた • 論文には自動販売機のみ（シーケンス図5つ） • 状態数や合成にかかる時間の簡単な評価はあり • ユーザスタディ（デバッグ時間とか）は言及なし

  12. F3. Unifying FSM-Inference Algorithms throughDeclarative Specification 担当：今井健男（T芝） by Ivan Beschastnikh , Yuriy Brun , Jenny Abrahamson , Michael D. Ernst , and Arvind Krishnamurthy

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

  14. ※ Fig. 3 実行ログから状態遷移モデル（FSM）を推定したい ※ Fig. 2 手続き的な推定アルゴリズム（大抵ハードコーディング）

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

  16. FSMの性質を宣言的に書けばそのとおりのFSMが出てくるツールを作りましたFSMの性質を宣言的に書けばそのとおりのFSMが出てくるツールを作りました こういうパターンを並べれば、お望みのFSMが出てくる • わかりやすい • 特徴がそのまま書いてある • いじりやすい • 追加・削除・マージ≒ 宣言を足したり引いたり • 比較しやすい • 並べて見比べればいい • （おまけ）性能もすんげく上がりました ※ Fig. 13

  17. F4.What Good Are Strong Specifications? by Nadia Polikarpova, Carlo A. Furia, Yu Pei, and Bertrand Meyer 担当：今井健男（T芝）

  18. ≒ complete みんないやがる 書くの大変 ≒ incomplete, partial みんなに人気 Design by Contract (DbC)実行可能な仕様だけ Test-Driven Development(TDD)テストケース＝形式仕様 強い形式仕様 vs. お手軽形式仕様 (strong) (lightweight) 強い仕様を書く価値はあるのか？ をエンピリカルに分析・評価 （＋「強い仕様/契約」の書き方の提案）

  19. 「線形リストの指定位置の後ろに、別のリストを挿入」の事後条件「線形リストの指定位置の後ろに、別のリストを挿入」の事後条件 お手軽仕様（DbC） 挿入後の要素数は2リストの要素数の合計 指定位置は 挿入前後で同じ ※ Fig. 1 より抜粋 強い仕様（Model-Based Contract, MBC） ※ Fig. 2 より抜粋 ただし sequence, front, tail, ‘+’ は別に与える

  20. 分析・評価してみた • 21種のEiffelコードに対するDbCとMBCで比較 • 総テストケース8700万個、総テスト時間1680時間（！）分のテスト生成、バグの見つかり方を比較 結果（の一部をざっくりと）： • MBCの方が、バグが2倍以上見つかった（103 vs. 48） • 記述量（仕様記述の行数/コード行数）もほぼ2倍程度（0.46 vs. 0.2） …労力に見合う効果はある

More Related