Recommended
More Related Content
What's hot
What's hot (20)
TLA+についての話
- 2. このスライドでわかること • 形式仕様言語まわりのさわりがわかる • ソフトウェアの品質を上げるための重要な手法だと認識できる • 導入事例と成功事例について学べる • TLA+のさわり • 簡単な仕様を定義してみてTLA+のさわりがわかる • 基本的な用語を確認できる • TLC Model Checkerの使い方がわかる • TLA Model Checkerに何ができるのかがわかる • ちょっとした仕様バグを検証できるようになる 2
- 3. TLA+とは？ • 形式仕様言語の一つ • 並行（Concurrent）システムの仕様記述が得意 • 多彩な時間表現 • 並行システムの表現が得意 • テスト可能な形式仕様 • TLC Model Checker：モデルチェッカー • TLAPS：定理証明支援系 • 普及も進む • 分散システムの論文にはTLA+ Specificationが付属 • Amazonなども活用して成果を上げている • 実は1999年に出てきたもので、目新しいものではない • 研究開始は1980年代 • 論文自体は1990年に出ている Amir Pnueli Leslie Lamport 3
- 4. 形式仕様言語とは (Formal Specification Language) • 数学的手法に基づいた厳密な記法でシステムのふるまいを表現 • 他の有名な形式仕様言語 • Alloy • Spin • VDM++ • TLA+ 4
- 5. 形式仕様言語の強み • 自然言語（英語とか日本語 etc..）で書かれた仕様書はあいまい • 読み手に暗に知識（常識）を求める • 同じ言葉が異なる意味でつかわれる • 条件が列挙された時の優先度が不明瞭 • 互いに矛盾する条項があっても気づきにくい • etc.. • 形式仕様言語なら • あいまいさを排除できる • 厳密なルールに基づいた仕様記述フレームワーク • 思考の制限による仕様の明晰化 • システマティックな検査手法が使える • バグ発見しやすくなる • モデルチェッカーの支援 • 定理証明支援系の支援 5
- 6. Theorem Proving v.s. Model checking • 証明（Theorem proving） • アドバンテージ • すべての状態を網羅できる • 制約 • 人間の手が必要（一部プログラムが補助してくれることがある） • エキスパートしか使えない • モデルチェッカー（Model checking） • 取りうる状態をすべて列挙し、しらみつぶしチェックする、そして悪いことが起こ らないかどうかチェック • アドバンテージ • 自動的にやってくれる • 制約 • モデル内の状態しかチェックできない • ブルートフォースなので状態爆発してしまうことがある • Simpleなモデルでしか扱えない 6
- 7. 仕様と実装 • 仕様とは？ • 「どのような状態を満たすと想定しているのか」を記述 • 「どのような状態になってはいけないのか」を記述 • 形式仕様言語とは仕様を定義する言語である • プログラミング言語のように「実行」するわけではない • HOWではなくWHATを定義 • 赤信号が点灯しているとき、歩行者は歩行を止める • システムの本質に関係ないところは仕様ではない • 信号の球はLEDなのか？それとも電球なのか？ • 信号は縦置き式なのか？それとも横置き式なのか？ 7
- 8. Amazonによる導入事例[1/3] • AWSでの導入 • 2011年からTLA+を導入開始 • How Amazon Web Services Users Formal Methodsという論文にまと まっている • TLA+だけでなくPlusCalも使っている • 2011年のDynamoDBリリースはTLA+のおかげ • PlusCal • TLA＋はとっつきにくい記法なのでプログラミング言語っぽくかける 形式仕様言語 • 内部的にはTLA+に変換しているようである 8
- 10. Amazonによる導入事例[3/3] • かんたーんTLA＋ • エンジニアは2～３週間程度で学習できる • とはいえやはり先入観はあったのか…（笑） • 「設計をデバッグする」という言葉を使った • 「形式」「検証」「証明」という言葉は使わず社内で布教した • TLA+の表現力への言及 • Alloyと呼ばれる形式仕様言語の導入を検討したが、AWSの仕様を表現 するのには耐えなかった • TLA+の表現力は高い？ 10
- 11. SQUARE ENIXでの導入事例 • FINAL FANTASY XV POCKET EDITION • 使っているらしい • Amazonみたいな詳細がでているわけではない • 一貫性のある実装ができているかをチェック • トランザクションのないDynamoDBを利用している • 一貫性が保たれなくても、本当に問題ないかをチェックしている https://d1.awsstatic.com/events/jp/2018/summit/tokyo/customer/37.pdf11
- 13. 時計の仕様を定義する • デジタル時計を考える • 11 -> 12 -> 1 -> 3 -> 4 … • 12進法の時計 • 分表示なし • 室温表示も考える • セ氏の室温計 • TLA+のさわりをわかってもらう • 時間表示時計（hour-clock）を定義 • 室温計も追加で定義する • 用語を覚えてもらう 13
- 14. 時間表示の仕様 [hr = 11] -> [hr = 12] -> [hr = 1] -> [hr = 2] -> … • 初期状態 (initial predicate) を定義 • hr 変数が初期状態で取りうる値を定義する • 何時から始まるのか？は考えないものとする • 何時からでも始まってもよいはずである • 次の状態を定義する（next-state relation） • hr が初期状態からどのように遷移するのか 14
- 15. 時間表示の仕様 • 初期状態 (initial predicate) の定義 • 初期状態 HCini の定義 • 初期状態 HCini において、変数 hr は{1, … , 12}のいずれかに属する • 明確に変数 hr がとりうる値を定義できる • 次の状態（next-state relation）を定義する • 次の遷移状態 HCnxt を定義する これは＝（イコール）だと 考えてください hr’ は新しいhr の値という意 味で使える 15
- 16. 時間表示の仕様 • 初期状態 (initial predicate) の定義 • 初期状態 HCini の定義 • 初期状態 HCini において、変数 hr は{1, … , 12}のいずれかに属する • 明確に変数 hr がとりうる値を定義できる • 次の状態（next-state relation）を定義する • 次の遷移状態 HCnxt を定義する これはstate これはaction ちゃんと区別しましょう prime (‘) 付きの式はaction、初期状態を定義しているのはstate これをしっかり区別しないと後々ややこしくなる 16
- 17. 時間表示の仕様 • 挙動（behavior）のつながりであらわされる • TLA+にはこのような時間の概念がある • （時相論理）Temporal Logicと呼ばれる論理体系が背景にある • 使われている記号もTemporal Logic由来 ・・・∞ State (Initial predicate) Action （next-state relation） Step 17
- 18. 時間表示の仕様 • 二つの仕様（HCini, HCnxt）を一つにする • □とは？ • pronounced box • □F とは F が 常に (always) true であるということです • 「つねに（always）」と解釈すればいい • この式 (formula) がtrueになるとき • 初期状態がHCiniを満たして、かつ、HCinit のすべてのステップが HTCnxtを満たす かつその時に限り true になる ・・・ すべてのステップで満たされる が定義できた 18
- 19. 室温計表示の仕様を追加してみよう • 室温表示 を追加するとどうなる？ • [hr = 11, tmp = 23.5] -> [hr = 12, tmp = 23.5] -> [hr = 12, tmp = 23.4] -> [hr = 12, tmp = 23.3] -> [hr = 1, tmp = 23.3] • 時間に加えて室温も表示する場合を考えてみる • stuttering step • hr表示がそのままでtmpだけ変わるのはありうる • tmpが変わるときはhrも変わらないといけないのは仕様として変 • hrが変わらずに次の状態に遷移する、つまりtmpだけ変わってもよい • 「時計のstuttering step」と言う stuttering stepを許容するように仕様を記述すべき 19
- 20. stuttering stepを許容する • HCini が成り立ち、また、 HCnxt もしくは hr` が hr のまま （不変のまま）次のstepに遷移する（ことが常に成り立つ） • 時刻が変化することなく、温度だけが変わってもいいよ！ こう変更する こういう便利記法 があります これはtemporal 20
- 21. stuttering stepを許容しないとどうなる？ • 現実的ではない • global clockは存在しえない • stuttering step許容しない＝暗にglobal clockを仮定している • おかしな仕様になりがち • 拡張性に乏しい仕様に陥りがち • 仕様Aを策定したのち、ほかの仕様Bを追加したくなったら？ • Aも満たして、かつ、Bも満たすという仕様を書かないといけない • stuttering stepを許容してなかったらどうなるだろうか？ • 先の室温計追加の例はまさにそれ • 書き下した変数のみが存在するわけではない • この世に存在しうるすべての仕様の中からhr, tmpを書き下しただけ • hrのみが存在する世界を考えてはいけない https://lamport.azurewebsites.net/tla/stuttering.html?back-link=advanced.html21
- 22. ここまでのまとめ • 時計の仕様の本質はこれでまとまっている • 温度計の例はstuttering stepの説明のためだけに入れたので省いた • TLA+の仕様としてまだ足りていない • 時計の仕様をモジュールとしてまとめる • 使用する外部モジュール（Naturals）を宣言 • 使用する変数の宣言 • 定理（THEOREM）の定義 22
- 25. 最終的なTLA+仕様[2/2] • 定理（THEOREM）とはなにか？ • その仕様が満たさなければならない条件を定義したもの • Correctnessを定義するのに使用 • 時計の仕様のCorrectnessとは？ • hrの値が１から12の範囲に収まること • hr = -100 とか hr = √12 とか hr = ‘hello’ とかになってはいけない！ • ⇒とは？ • HCであるということは□HCini が成り立つということ • □HCiniであるからと言ってHCが成り立つわけじゃない • だから＝は使わない 25※ 後述するTLC Model Checkerを使うことだけを考えるとTHEOREMは書かなくてもよい
- 27. TLA+による仕様記述のまとめ • 仕様定義の仕方 • 初期状態を定義する • 次に起こる状態を定義する • stuttering stepを許容する • global clockの存在を仮定してはいけない • 書き下した変数のみの世界が存在するわけではない • THEOREMを定義する • その仕様が満たすべき条件の定義 • 用語を覚えて区別しよう • state: VARIABLEを使っているもの • action: prime付VARIABLEを使っているもの • temporal: temporal operator（□など）を使っているもの 27
- 28. TLA+の表現力 • 多彩なtemporal operatorが使用可能 • □F以外にもたくさんあります • ◇F ≡ ￢□￢F • Fがtrueではないことが常に（always）なりたつことはない • いつか（eventually）Fがtrueになる • F G ≡ □(F⇒◇G) • FがいつtrueであろうとGはいつか（eventually）trueになる • どの地点のFがtrueになるstepを選んでも、そこから先はGがtrueになるstepが少なく とも一つ存在する • ◇〈A〉v • vが変更されてAがtrueであるというstepがいつか（eventually）おこる • □◇F • 任意のstepにおいて、そのstepより先のいくつかのstepではFが成り立つ • ※注意 • □F ⇒ □◇ F は成り立つ • □◇ F ⇒ □F は成り立たない • □◇ F ≡ □F は成り立たない 28
- 30. TLC Model Checkerができること • 不変式（Invariants）の検証 • 定義したstateが初期状態から派生するすべての状態で成り立つかの検証 • 特性（Properties）の検証 • だいたいLivenessやFairnessの検証になる • Silliness error検出 • 意味をなさない記述を見つけてくれる • e.g.) t = “abc” + 10 • Deadlock検出 • 完全ではない • 「これ以上やることがないので停止」状態と「回復不可能な停止」の区別 • 後者をDeadlockと呼ぶことが多いように思うがTLCは区別できない 30
- 32. 不変式（Invariants）の検証[2/4] • 時計の仕様を以下のように書き換えてみる 32 この仕様。バグがある hrは1から12を繰り返すはずなのに、不変式 (Inv) では hrは1から11の値をとると記述してしまっている
- 33. 不変式（Invariants）の検証[3/4] • SPECファイル（SPEC.cfg）を作る • TLC Model Checkerにどのようなチェックを行うかを指示 • テキストファイルで作成する 33 チェックする仕様を指定 （今回は定義したHCが対象となる） 今回はInvariantsの検証なので検証したい 不変式であるInvを指定する TLA ToolboxというGUIでも操作できるが、現実的な仕様検 証の場合、計算機パワーをかなり食うので、高性能マシン にSSHで入って使うのが普通だとおもう。ので、CUI操作に 慣れたほうが良い
- 34. 不変式（Invariants）の検証[4/4] • 実行結果 34 初期状態 hr = 12 の場合において 不変式が破られると教えてくれる
- 35. 仕様バグを潰せた • 矛盾した仕様を書いてしまっても気付かせてくれる • 1 から 12 までの表示のはずなのに1 から 11までの表示しかないと不 変式を定義してしまっていた • 今回の例は単純だったが、複雑な仕様になればなるほど「仕様の定義 の矛盾、バグ」にはどんどん気づきにくくなる • 自分自身の思考も整理できる • 仕様がまちがっている？ • INVARIANTが間違っている？ • なぜ自分はそう書いた？単純なタイプミス？それとも自分の考えや仮 定に何か根本的な誤りがないか？ 35
- 37. TLA+の使いどころ • どのように使うべきか？ • 設計者が設計段階で対話的に使っていい • 設計者自身の考えも明晰にできる • 検証した設計から実行可能な正しいコードはどうやって得る？ • 「そんなもんはない！」 • しかし… • どうあがいても「間違った設計」からは「間違った実装」しか得られない • 一部テストコードの一部を得られることはある • TLA+ではシステムの不変条件を記述していく • そこから、機械的にテストコードが得られることがある • 仕様でバグってたら実装ではどうあがいても取り戻せない • ましな道があるのだからやるべき • Amazonは成功している 37
- 38. どうやって学ぶか？ • Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers を読む • 発明者Leslie Lamport先生じきじきの書下ろし本 • 明瞭かつ簡潔に書かれていてわかりやすい • Practical TLA+: Planning Driven Development • ちゃんとよんでないけどAmazonでの評価は高い • どちらかというとPlusCalより • 日本語の情報はあんまりないです 38
- 39. TLA Toolbox • IDEがあるよ！ • コード成型 • ACSIIコードの色付け • LaTeXコードの生成 • TLC Model Checker呼び出し • 前述したがCUIに慣れたほうよい 39 https://lamport.azurewebsites.net/tla/toolbox.html