![Stack Preconditions
remove(s:STACK[G]) require not empty(s)
item(s:STACK[G]) require not empty(s)](https://image.slidesharecdn.com/howtoread-140628050010-phpapp02/85/kyon_mm-AsianAA-12-320.jpg)
@kyon_mmの書籍の読み方 #AsianAA
- 1. How to read
- 2. 関西に最近くると聞かれる
- 3. • 「きょんさんってたくさん書籍読みますよ ね」 • 「そうかもしれませんね」 • 「一ヶ月でどれくらい読むんですか？」 • 「うーん。あまり測っていないかも。。。 多分年間で数十冊くらい。」 • 「どうやって読むんですか？」 • 「えっとですね。。。」
- 4. 1. まず目次から内容を予想する。30分くら い。 2. 3日で全部読む。わからないところは飛ば す。言い回しや価値のある部分を知る。 3. マインドマップでわからないことを書く。 4. 次はじっくり全部読む。 5. マインドマップでわかったことを削除する。 わからないことは追加する。 6. 変更量をメトリクスする。
- 9. Design by Contractでの設計 と保証 1. 事前条件、公理を定義する 2. 事前条件、事後条件、不変条件として定義 する 3. 実装する まぁ、ホーア論理だよ。P {C} Q だよ。
- 10. DbCとCoqはどう違うのか？ • 全然わかりません。 • コンパイルタイムチェックの契約プログラミン グと依存型プログラミングは結構似ている。 • DbCは停止性を証明する必要はないけど、 Coqは停止性を証明する必要がある。
- 11. 「振る舞い」か「公理」か
- 12. Stack Preconditions remove(s:STACK[G]) require not empty(s) item(s:STACK[G]) require not empty(s)
- 13. Stack Aximos item(put(s, x)) = x remove(put(s, x)) = x empty(new) not empty(put(s, x))
- 14. 比較 • TDD : ある集合の具体的な値をなにかの形 で実行時検査するしか保証がとれない。 • DbC : 公理を満たさないモジュールは定義 できない。
- 15. 比較 • TDD : ユースケースを書くけど、ユースケー スは網羅されていない。 • DbC : 公理は比較的網羅する方向にある。 書かないと警告ばっかりでるからな！