Design by Contractと

ホーア論理

Presenter : kmt-t

1

自己紹介

ハンドルネーム

• 正式には「kmt-t」

• はてなID : kmt-t2

• Twitter ID : kmt_t

• 大阪に「出稼ぎ」中です

• 鳥取に帰ろうとしてその度に阻止されています…orz

居住地

属性など

• いわゆる「組み込み屋」です

• 言語的にはC/C++/C#

• ミドルウェア(2D/3Dグラフィックス、ファイルシステムなど)

Design by Contractを知っていますか？

2

知っている人は挙手！

3

Design by Contractとは

• ある手続きが事前に満たすべき条件

事前条件

以上の条件を満たすことをプログラム上に記述する

• C/C++ではAssertで記述することが多い

• Eiffelでは言語でサポートしているらしい (触ったことありません)

• ちょっと遠いところではUMLのユースケース記述でも同じような記述をするよね？

• ある手続きが事後に満たすべき条件

事後条件

• ある手続きが常に満たすべき条件

不変条件

4

Design by Contractの効果

• 処理の実装者側と利用者側とでコミュニケーションミスを減らす

仕様を明確にする

オブジェクト指向言語でのインターフェイスにおいて効果大

• インターフェイスは、型以外の正しさの基準の情報がない

• Design by Contractを適用すれば、実装者、利用者に正しさの基準を提供できる

• 事前条件を満たすのに事後条件を満たさないのは仕様か実装のバグ

実装のバグを検出する

• ある手続きを利用するのに事前条件を満たしていないのは利用者のバグ

利用者のバグを検出する

5

ちょっと数学的な例 – 事前条件

• 関数𝑠𝑞𝑟𝑡は正の整数しか引数に取れない

平方根を計算する関数𝑠𝑞𝑟𝑡

ちょっとだけ数学用語の確認

• y = 𝑠𝑞𝑟𝑡 𝑥 , 𝑥 ∈ 𝑋, 𝑦 ∈ 𝑌

• 集合𝑋を関数𝑠𝑞𝑟𝑡の定義域(domain) と呼ぶ

• 集合𝑌を関数𝑠𝑞𝑟𝑡の値域 (codomain) と呼ぶ

• この例の事前条件は「引数が定義域の集合に含まれているか」

• 「引数として正の整数を与えること」が事前条件になる

• 事前条件を満たさない場合の動作は未定義で問題ない

6

ちょっと数学的な例 – 事後条件

• 関数𝑠𝑞𝑟𝑡の戻り値は必ず正の整数

平方根を計算する関数𝑠𝑞𝑟𝑡

ちょっとだけ数学的な表現にすると

• この例の事後条件は「戻り値が値域の集合に含まれているか」

• 「戻り値は必ず正」が事後条件になる

• 関数𝑠𝑞𝑟𝑡が事後条件を満たさない場合、バグである

• 実際のプログラムでは事後条件は戻り値のみに適用されるわけではないのに注意

7

ちょっと数学的な例 – 不変条件

• 残高はマイナスにならない

• 残高は100円単位でしか使用できない

• 残高は最大で50000円までしかチャージできない

• 以上は不変条件として定義することができる

プリペイドカードを定義するPrepaid型

型の取りうる値を定義

• この例では型の取りうる値を定義している

• 本来は言語組み込み型の値が実際に取りうる値と一致することは稀

8

Design by Contractのバックグラウンド

• Design by Contractは経験則から導かれたものではない

• Design by Contractは数学的なバックグラウンドを持つ

• Design by Contractはホーア論理 (または公理的意味論) をベースにした形式仕様記述をカジュアル化したもの

Design by Contractは形式仕様記述をカジュアルにしたもの

形式仕様記述とは

• ある決まった規則を適用することができる手法を形式手法と言う

– 人間よりコンピュータで処理しやすい場合が比較的多い

• ここで言うホーア論理をベースとした形式仕様記述では仕様 (事前条件、事後条件、不変条件) を満たすことを証明することで、プログラムの正当性を証明できる

• ホーア論理をベースとした形式仕様記述の言語の例

– Z言語

– VDM/VDM SL/VDM++

– OCL (UMLの仕様に含まれる、形式仕様記述言語)

9

プログラムの正しさとは？

• プログラムの正しさとは、正しさの基準 (一般的には仕様と呼ぶ) に対して合致しているかどうかで決まる

プログラムの正しさとは相対的なもの

正しさと仕様の例

• 関数𝑠𝑜𝑟𝑡の仕様を考えてみる

• 以下の仕様を見たす実装としてはクイックソート、マージソートどちらでも良い

– 事後条件として配列の前の要素より後の要素のほうが必ず値が大きい

• しかし以下の仕様を満たすのはマージソートであり、クイックソートではない

– 事後条件として配列の前の要素より後の要素のほうが必ず値が大きい

– 事後条件として整列の結果が安定でなければならない

• このようにプログラムの正しさとは仕様で決まる

10

ホーア論理とは

考案者はアントニー・ホーアさん

• 一番有名なのはクイックソートの発明者

• CSP (Communicating Sequential Processes) の考案者

• プログラムの正しさの基準 (仕様) を提供するための論理

• 事前条件、事後条件が正しさの基準として妥当であることが帰納法をつかって数学的に証明されている

ホーア論理とは

• ある起点となる論理から再帰的に別の論理が正しいことを示す証明方法

• 髪の毛ゼロ本の人はハゲである、ハゲの人より髪の毛一本多い人もハゲである、よってすべての人はハゲである、というジョークが帰納法

帰納法とは

11

ここで簡単な論理式の記法のおさらい

• 命題論理

– 「 𝐴ではない」の場合、以下のように書く

¬A – 「𝐴または𝐵」の場合、以下のように書く

𝐴⋁𝐵 – 「𝐴かつ𝐵」の場合、以下のように書く

𝐴 ∧ 𝐵 – 「𝐴ならば𝐵」の場合、以下のように書く

𝐴 → 𝐵 • 述語論理

– 「𝑥について述語𝑃が成り立つ」場合、以下のように書く

𝑃(𝑥)

以下の論理式は押さえておく

12

ここで簡単な論理式の記法のおさらい

• 集合

– 「集合𝐴のすべての要素について述語𝑃は真である」場合

∀𝑥 ∈ 𝐴, 𝑃(𝑥) – 「集合𝐴のいずれかの要素について述語𝑃が真である」場合

∃𝑥 ∈ 𝐴, 𝑃(𝑥) • 代入

– 「論理式𝑃のすべての自由変項𝑥を式𝐸で置き換える」場合

𝑃[𝑥 𝐸 ] • 演繹

– 「前提𝑃 → 𝑄, 𝑄 → 𝑅が成り立つとき、結論𝑃 → 𝑅が成り立つ」場合

𝑃 → 𝑄,𝑄 → 𝑅

𝑃 → 𝑅

以下の論理式は押さえておく

13

Hoare Triple

• Hoare Tripleの書き方

𝑃 𝐶 𝑄 – 𝑃は事前条件

– 𝑄は事後条件

– 𝐶はコード

• Hoare Tripleにより事前条件、事後条件を論理式で表せる

Hoare Tripleとは論理式でホーア論理を記述したもの

14

ホーア論理を構成する公理と規則

• 空文の公理

• 代入の公理

• 逐次規則

• 条件規則

• While規則

• 結果規則

ホーア論理は以下の公理と規則で構成されている

15

空文の公理

𝑃 𝑝𝑎𝑠𝑠 {𝑃}

• 空文は前提条件なしに事前条件および事後条件として同じ論理式𝑃を表明できる

空文の公理とは

16

代入の公理

𝑃 𝑥 𝐸 𝑥 ≔ 𝐸 {𝑃}

• 前提なしで上記のHoare Tripleが成り立つ

代入の公理とは

• 論理式𝑃には論理式y = 43, 𝑥 = 42が含まれていることとする

• 変項𝑦に𝑥 + 1を代入すると以下の様なHoare Tripleとなる

𝑥 + 1 = 43 ∧ 𝑥 = 42 𝑦 ≔ 𝑥 + 1 𝑦 = 43 ∧ 𝑥 = 42 • 事後条件の変項𝑦が事前条件では式𝑥 + 1に置き換えられている

具体例

17

逐次規則

𝑃 𝑆 𝑄 , 𝑄 𝑇 {𝑅}

𝑃 𝑆; 𝑇 {𝑅}

• ふたつ手続きが続けて実行される場合、最初の式の事前条件Pと後の式の事後条件𝑅を複合文の事前条件、事後条件として表明できる

逐次規則とは

𝑥 + 1 = 43 𝑦: = 𝑥 + 1 𝑦 = 43 , 𝑦 = 43 𝑧: = 𝑦 {𝑧 = 43}

𝑥 + 1 = 43 𝑦:= 𝑥 + 1; 𝑧: = 𝑦 {𝑧 = 43}

具体例

18

条件規則

𝐵 ∧ 𝑃 𝑆 𝑄 , ¬𝐵 ∧ 𝑃 𝑇 {𝑄}

𝑃 𝑖𝑓 𝐵 𝑡ℎ𝑒𝑛 𝑆 𝑒𝑙𝑠𝑒 𝑇 𝑒𝑛𝑑𝑖𝑓 {𝑄}

• 条件𝐵が成り立つ場合は手続きS、成り立たない場合は手続き𝑇となる

• ただしどちらでも事前条件𝑃と事後条件𝑄を表明できる

条件規則とは

19

While規則

𝑃 ∧ 𝐵 𝑆 𝑃

𝑃 𝑤ℎ𝑖𝑙𝑒 𝐵 𝑑𝑜 𝑆 𝑑𝑜𝑛𝑒 {¬𝐵 ∧ 𝑃}

• 手続き𝑆を論理式𝐵が成り立つ間繰り返す

• 繰り返しが終了すると¬𝐵となる

While規則とは

20

結果規則

𝑃′ → 𝑃, 𝑃 𝑆 𝑄 , 𝑄 → 𝑄′

𝑃′ 𝑆 {𝑄′}

• 論理包含によって事前条件を制限、事後条件を拡張することができる

結果規則とは

P

P’

Q’

Q

S

帰納法を使って証明してみる

21

• 「逐次」に対応する「逐次規則」

• 「条件」に対応する「条件規則」

• 「繰り返し」に対応する「While規則」

• 公理、規則を帰納的に当てはめることで、ホーア論理でどんなに長いプログラムの正当性でも検証できることが証明できる

• 今回は細かい証明は割愛しますが、割りと受け入れやすい結論だと思われる

手続き型言語を構成する制御は、「逐次」「条件」「繰り返し」のみ

完全正当性のためのWhile規則

22

• 今まで説明した公理と規則では、実はプログラムが停止しない場合、正しさの証明ができない

• そのため今までの公理と規則で証明した場合、「部分的正当性の証明」と呼ぶ

部分的正当性の証明

• 完全正当性の証明には「ループごとに絶対に減少するカウンタ」をWhile規則に組み込むことでプログラムが確実に終了することを示す

𝑃 ∧ 𝐵 ∧ 𝑡 = 𝑧 𝑆 𝑃 ∧ 𝑡 < 𝑧 , 𝑃 → 𝑡 ≥ 0

𝑃 𝑤ℎ𝑖𝑙𝑒 𝐵 𝑑𝑜 𝑆 𝑑𝑜𝑛𝑒 {¬𝐵 ∧ 𝑃}

• ただしこの規則を導入したプログラムはチューリング完全ではなくなる

• 完全なプログラムの停止性は証明不可能なので、どちらを取るかになる

完全正当性の証明

ホーア論理を満たしていることを示す方法

23

• 方法はふたつ

1. 定理証明器 (Coqなど) などを使って証明する

2. テストをする

プログラムがホーア論理を満たしていることを示す方法

• プログラムが正しいことが証明でき、間違いがない

• 自明なプログラムが証明が簡単とは限らない

• 普通の感覚では証明のコストが高すぎる

証明する方法

• 現実的な方法だが、テスト条件でバグがないことしか検査できない

テストする方法

UMLにおけるホーア論理

24

• UMLにおける形式仕様記述言語

• 事前条件、事後条件、不変条件を記述する

• http://ja.wikipedia.org/wiki/Object_Constraint_Language

OCL

• 副作用がない

• 宣言的である

• 関数型プログラマの人にはとっつきやすいと思われる

特徴

• MDAでは構成要素として利用されている様子

応用されている分野

ホーア論理の応用範囲

25

• ホーア論理の応用範囲は詳細設計、実装にとどまらない

• 要件定義の段階から仕様の矛盾、コミュニケーションミスを減らすために使える

要件定義から詳細設計、実装まで

今日の発表の教科書など

26

プログラム仕様記述論

• 形式仕様記述の教科書で非常に平易でわかりやすい

• 入門書としてはお勧め

• 荒木啓二郎 張漢明

• ISBN : 4-274-13263-3

ソフトウェア開発のモデル化技法

• VDM-SLの実際に適用するケーススタディの本

• ジョン・フィッツジェラルド ペーター・ゴルム ラーセン

• ISBN : 4-00-005609-3

• 新しめの本としては「VDM++による形式仕様記述(ISBN : 4764904098)」なども

ご清聴ありがとうございました

27