Design by Contractとホーア論理

Transcript

1. Design by Contractと ホーア論理 Presenter : kmt-t
2. 1 自己紹介 ハンドルネーム • 正式には「kmt-t」 • はてなID : kmt-t2 • Twitter ID : kmt_t • 大阪に「出稼ぎ」中です • 鳥取に帰ろうとしてその度に阻止されています…orz 居住地 属性など • いわゆる「組み込み屋」です • 言語的にはC/C++/C# • ミドルウェア(2D/3Dグラフィックス、ファイルシステムなど)
3. Design by Contractを知っていますか？ 2 知っている人は挙手！
4. 3 Design by Contractとは • ある手続きが事前に満たすべき条件 事前条件 以上の条件を満たすことをプログラム上に記述する • C/C++ではAssertで記述することが多い • Eiffelでは言語でサポートしているらしい (触ったことありません) • ちょっと遠いところではUMLのユースケース記述でも同じような記述をするよね？ • ある手続きが事後に満たすべき条件 事後条件 • ある手続きが常に満たすべき条件 不変条件
5. 4 Design by Contractの効果 • 処理の実装者側と利用者側とでコミュニケーションミスを減らす 仕様を明確にする オブジェクト指向言語でのインターフェイスにおいて効果大 • インターフェイスは、型以外の正しさの基準の情報がない • Design by Contractを適用すれば、実装者、利用者に正しさの基準を提供できる • 事前条件を満たすのに事後条件を満たさないのは仕様か実装のバグ 実装のバグを検出する • ある手続きを利用するのに事前条件を満たしていないのは利用者のバグ 利用者のバグを検出する
6. 5 ちょっと数学的な例 – 事前条件 • 関数は正の実数しか引数に取れない 平方根を計算する関数 ちょっとだけ数学用語の確認 • y = , ∈ , ∈ • 集合を関数の定義域(domain) と呼ぶ • 集合を関数の値域 (codomain) と呼ぶ • この例の事前条件は「引数が定義域の集合に含まれているか」 • 「引数として正の実数を与えること」が事前条件になる • 事前条件を満たさない場合の動作は未定義で問題ない
7. 6 ちょっと数学的な例 – 事後条件 • 関数の戻り値は必ず正の実数 平方根を計算する関数 ちょっとだけ数学的な表現にすると • この例の事後条件は「戻り値が値域の集合に含まれているか」 • 「戻り値は必ず正」が事後条件になる • 関数が事後条件を満たさない場合、バグである • 実際のプログラムでは事後条件は戻り値のみに適用されるわけではないのに注意
8. 7 ちょっと数学的な例 – 不変条件 • 残高はマイナスにならない • 残高は100円単位でしか使用できない • 残高は最大で50000円までしかチャージできない • 以上は不変条件として定義することができる プリペイドカードを定義するPrepaid型 型の取りうる値を定義 • この例では型の取りうる値を定義している • 本来は言語組み込み型の値が実際に取りうる値と一致することは稀
9. 8 Design by Contractのバックグラウンド • Design by Contractは経験則から導かれたものではない • Design by Contractは数学的なバックグラウンドを持つ • Design by Contractはホーア論理 (または公理的意味論) をベースにした形式仕 様記述をカジュアル化したもの Design by Contractは形式仕様記述をカジュアルにしたもの 形式仕様記述とは • ある決まった規則を適用することができる手法を形式手法と言う – 人間よりコンピュータで処理しやすい場合が比較的多い • ここで言うホーア論理をベースとした形式仕様記述では仕様 (事前条件、事後条件、 不変条件) を満たすことを証明することで、プログラムの正当性を証明できる • ホーア論理をベースとした形式仕様記述の言語の例 – Z言語 – VDM/VDM SL/VDM++ – OCL (UMLの仕様に含まれる、形式仕様記述言語)
10. 9 プログラムの正しさとは？ • プログラムの正しさとは、正しさの基準 (一般的には仕様と呼ぶ) に対して合致して いるかどうかで決まる プログラムの正しさとは相対的なもの 正しさと仕様の例 • 関数の仕様を考えてみる • 以下の仕様を見たす実装としてはクイックソート、マージソートどちらでも良い – 事後条件として配列の前の要素より後の要素のほうが必ず値が大きい • しかし以下の仕様を満たすのはマージソートであり、クイックソートではない – 事後条件として配列の前の要素より後の要素のほうが必ず値が大きい – 事後条件として整列の結果が安定でなければならない • このようにプログラムの正しさとは仕様で決まる
11. 10 ホーア論理とは 考案者はアントニー・ホーアさん • 一番有名なのはクイックソートの発明者 • CSP (Communicating Sequential Processes) の考案者 • プログラムの正しさの基準 (仕様) を提供するための論理 • 事前条件、事後条件が正しさの基準として妥当であることが帰納法をつかって数学 的に証明されている ホーア論理とは • ある起点となる論理から再帰的に別の論理が正しいことを示す証明方法 • 髪の毛ゼロ本の人はハゲである、ハゲの人より髪の毛一本多い人もハゲである、 よってすべての人はハゲである、というジョークが帰納法 帰納法とは
12. 11 ここで簡単な論理式の記法のおさらい • 命題論理 – 「 ではない」の場合、以下のように書く ¬A – 「または」の場合、以下のように書く ⋁ – 「かつ」の場合、以下のように書く ∧ – 「ならば」の場合、以下のように書く → • 述語論理 – 「について述語が成り立つ」場合、以下のように書く () 以下の論理式は押さえておく
13. 12 ここで簡単な論理式の記法のおさらい • 集合 – 「集合のすべての要素について述語は真である」場合 ∀ ∈ , () – 「集合のいずれかの要素について述語が真である」場合 ∃ ∈ , () • 代入 – 「論理式のすべての自由変項を式で置き換える」場合 [ Τ ] • 演繹 – 「前提 → , → が成り立つとき、結論 → が成り立つ」場合 → , → → 以下の論理式は押さえておく
14. 13 Hoare Triple • Hoare Tripleの書き方 – は事前条件 – は事後条件 – はコード • Hoare Tripleにより事前条件、事後条件を論理式で表せる Hoare Tripleとは論理式でホーア論理を記述したもの
15. 14 ホーア論理を構成する公理と規則 • 空文の公理 • 代入の公理 • 逐次規則 • 条件規則 • While規則 • 結果規則 ホーア論理は以下の公理と規則で構成されている
16. 15 空文の公理 {} • 空文は前提条件なしに事前条件および事後条件として同じ論理式を表明できる 空文の公理とは
17. 16 代入の公理 Τ ≔ {} • 前提なしで上記のHoare Tripleが成り立つ 代入の公理とは • 論理式には論理式y = 43, = 42が含まれていることとする • 変項に + 1を代入すると以下の様なHoare Tripleとなる + 1 = 43 ∧ = 42 ≔ + 1 = 43 ∧ = 42 • 事後条件の変項が事前条件では式 + 1に置き換えられている 具体例
18. 17 逐次規則 , {} ; {} • ふたつ手続きが続けて実行される場合、最初の式の事前条件Pと後の式の事後条 件を複合文の事前条件、事後条件として表明できる 逐次規則とは + 1 = 43 : = + 1 = 43 , = 43 : = { = 43} + 1 = 43 : = + 1; : = { = 43} 具体例
19. 18 条件規則 ∧ , ¬ ∧ {} ℎ {} • 条件が成り立つ場合は手続きS、成り立たない場合は手続きとなる • ただしどちらでも事前条件と事後条件を表明できる 条件規則とは
20. 19 While規則 ∧ ℎ {¬ ∧ } • 手続きを論理式が成り立つ間繰り返す • 繰り返しが終了すると¬となる While規則とは
21. 20 結果規則 ′ → , , → ′ ′ {′} • 論理包含によって事前条件を制限、事後条件を拡張することができる 結果規則とは P P’ Q’ Q S
22. 帰納法を使って証明してみる 21 • 「逐次」に対応する「逐次規則」 • 「条件」に対応する「条件規則」 • 「繰り返し」に対応する「While規則」 • 公理、規則を帰納的に当てはめることで、ホーア論理でどんなに長いプログラムの 正当性でも検証できることが証明できる • 今回は細かい証明は割愛しますが、割りと受け入れやすい結論だと思われる 手続き型言語を構成する制御は、「逐次」「条件」「繰り返し」のみ
23. 完全正当性のためのWhile規則 22 • 今まで説明した公理と規則では、実はプログラムが停止しない場合、正しさの証明 ができない • そのため今までの公理と規則で証明した場合、「部分的正当性の証明」と呼ぶ 部分的正当性の証明 • 完全正当性の証明には「ループごとに絶対に減少するカウンタ」をWhile規則に組 み込むことでプログラムが確実に終了することを示す ∧ ∧ = ∧ < , → ≥ 0 ℎ {¬ ∧ } • ただしこの規則を導入したプログラムはチューリング完全ではなくなる • 完全なプログラムの停止性は証明不可能なので、どちらを取るかになる 完全正当性の証明
24. ホーア論理を満たしていることを示す方法 23 • 方法はふたつ 1. 定理証明器 (Coqなど) などを使って証明する 2. テストをする プログラムがホーア論理を満たしていることを示す方法 • プログラムが正しいことが証明でき、間違いがない • 自明なプログラムが証明が簡単とは限らない • 普通の感覚では証明のコストが高すぎる 証明する方法 • 現実的な方法だが、テスト条件でバグがないことしか検査できない テストする方法
25. UMLにおけるホーア論理 24 • UMLにおける形式仕様記述言語 • 事前条件、事後条件、不変条件を記述する • http://ja.wikipedia.org/wiki/Object_Constraint_Language OCL • 副作用がない • 宣言的である • 関数型プログラマの人にはとっつきやすいと思われる 特徴 • MDAでは構成要素として利用されている様子 応用されている分野
26. ホーア論理の応用範囲 25 • ホーア論理の応用範囲は詳細設計、実装にとどまらない • 要件定義の段階から仕様の矛盾、コミュニケーションミスを減らすために使える 要件定義から詳細設計、実装まで
27. 今日の発表の教科書など 26 プログラム仕様記述論 • 形式仕様記述の教科書で非常に平易でわかりやすい • 入門書としてはお勧め • 荒木啓二郎 張漢明 • ISBN : 4-274-13263-3 ソフトウェア開発のモデル化技法 • VDM-SLの実際に適用するケーススタディの本 • ジョン・フィッツジェラルド ペーター・ゴルム ラーセン • ISBN : 4-00-005609-3 • 新しめの本としては「VDM++による形式仕様記述(ISBN : 4764904098)」なども
28. ご清聴ありがとうございました 27