ゲームとモデル検査ワークショップ#1

1,072 views
964 views

Published on

ハンズオンな資料です。

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,072
On SlideShare
0
From Embeds
0
Number of Embeds
43
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

ゲームとモデル検査ワークショップ#1

  1. 1. Copyright (C) 2013 National Institute of Informatics, All rights reserved. ゲームとモデル検査ワークショップ #1 2013年9月12日 国立情報学研究所 GRACEセンター/先端ICTセンター 長久勝 mailto : nagaku@nii.ac.jp Twitter : @mnagaku
  2. 2. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 2 じゅんび  http://code.9leap.net/ アカウントを持ってなかったら作る http://code.9leap.net/codes/show/34479 動作確認 Javascriptのコンソール表示方法を確認  LTSA  http://www.doc.ic.ac.uk/~jnm/book/ltsa/download.html 「download ltsa」からltsatool.zipをDL、 適当な場所に展開 ltsa.batでメモリ設定
  3. 3. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 3 そのいち、だっしゅつげえむ  ゲームのスクリプトに潜むバグを LTSAで取ってみます  http://code.9leap.net/codes/show/42604 ログインして、Forkして、自分用の環境を作る 実行するとLTSA用のモデルがconsoleに出る // FSP から下の記述 LTSAにコピペで持って行く
  4. 4. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 4 おれのあたまのなかのげーむしなりお do / 鍵取得=false 開始 さて進めて どんどん進めて ぐるぐる脱出最後のドア 探索 do / 鍵取得=true 鍵発見 もうないドア開 開く 開かない 終了 次へ 次へ 次へ 次へ 周りを探すドアを開ける 次へ [鍵取得==false] 次へ [鍵取得==true] 次へ 次へ 次へ [鍵取得==true] 次へ [鍵取得==false] 次へ 次へ 次へ
  5. 5. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 5 けんさできるせいしつのれい  const False = 0 const True = 1 fluent HAS_KEY = <{m.s鍵発見.s最後のドア}, {m.sさて進めて.sどんどん進めて}> initially False fluent OPEN_DOOR = <{m.s開く.s終了}, {m.sさて進めて.sどんどん進めて}> initially False assert P1 = [](OPEN_DOOR -> HAS_KEY)  イベントによって変化する状態を定義し、その状態の関係をLTLで検査式として書く  P1:ドアが開いた状態の時は、必ず鍵を持っている状態でなければならない  progress END = {m.s終了.s開始}  進行性検証  どんな状態からでも、いつか「m.s終了.s開始」のイベントを起こせる  「m.s終了.s開始」のイベントが起こせなくなる進行とは、エンディングに到達できないパスがあるということ  property Test = (m.s鍵発見.s最後のドア -> m.s開く.s終了 -> Test).  安全性検証  システムを抽象化(捨象)して守るべき性質を記述  「m.s鍵発見.s最後のドア」、「m.s開く.s終了」以外のイベントを無視した場合、システムが 「Test = (m.s鍵発見.s最後のドア -> m.s開く.s終了 -> Test)」 と等価か調べる  鍵を発見していないのにドアが開いたり、鍵を複数回発見してからドアが開いたりすると、等価にならない
  6. 6. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 6 そのに、さされる  http://code.9leap.net/codes/show/42607  const False = 0 const True = 1 fluent DEAD_ME = <{m.s死ぬ.s終了}, {m.s終了.s開始}> initially False fluent LIVE_CAT = <{m.s終了.s開始}, {m.s猫死ぬ.s死ぬ}> initially True assert P1 = [](DEAD_ME -> LIVE_CAT)  自分を殺すのが必ず猫だとした場合、 自分が死んだ時に、既に猫が死んでいたらおかしい  ほんとは、死んだら生き返らない検査項目も必要だけど、ここでは割愛  物語の内容についての制約も検査できる  モデル化に工夫しておくと、自動化も可能  キャラ表示命令から香盤表を自動生成して、その情報を使うとか  シーンにアノテーション(タグ)を付けて、遷移以外のイベントを自動で埋め込めるようにするとか
  7. 7. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 7 へいこうせい  モデル検査は 本来、並行システムの検証に用いられる LTSAのexample、6章の「食事する哲学者」  ADVスクリプトに書き下されたシナリオ進行では 並行性を扱わない 登場人物毎の振る舞いを 個別のプロセスと考えると並行システムになる 個別のプロセスが並行合成されて 単一プロセス化されている  並行性のないモデル化ができるので、 状態爆発を回避できる
  8. 8. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 8 げーむしなりおともでるけんさ  モデル化すると、 複雑さは、組み合わせの量に変換される  人間は量を扱えない、機械は量を扱える  複雑なシナリオを高品質で実現!

×