Your SlideShare is downloading. ×
エンジニア・ミーツ・Coq プラスワン
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

エンジニア・ミーツ・Coq プラスワン

1,627
views

Published on

2010/11/27に行われたCoqPartyという勉強会でのスライドです

2010/11/27に行われたCoqPartyという勉強会でのスライドです

Published in: Technology

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

No Downloads
Views
Total Views
1,627
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 2010/11/27 Coq Party モリグチ @wof_moriguchi
  • 2. 自己紹介• モリグチ(@wof_moriguchi)• メーカーの職業プログラマー(Windowsアプリ)• ソフトウェア開発の効率化・品質向上に興味• 2010年6月よりProofCafeに参加(Coq初心者) – 名古屋アジャイル勉強会 – 名古屋Scala勉強会
  • 3. 本日の発表について• 今日お話すること – 『すぐ分かる形式手法』 ←マジメ – 『エンジニア・ミーツ・Coq 』 ←あまりマジメじゃない (もともとは一本のスライドを前半と後半に分けたものです)• 今日お話しないこと – Coqでの難しい証明の話• 間違いや勘違いがあるかもしれませんが、その時は後でこっそり教えて下さい
  • 4. ここでは、まったくの初心者を対象に形式手法のメリットなどを紹介します。
  • 5. 形式手法とは?品質の高いソフトウェアを開発するための科学的な仕様記述・検証手法
  • 6. ウォーターフォール型開発(V字モデル) 要件定義 検証 システムテスト (仕様化) 外部設計 検証 結合テスト (システム設計) 内部設計 検証 単体テスト (モジュール設計) 開発実施 (プログラミング) 工程
  • 7. 従来のV字モデルの欠点要件定義 システムテスト(仕様化) 外部設計 結合テスト (システム設計) 誤り発見! 内部設計 単体テスト (モジュール設計) 手戻り 開発実施 修正・確認 (プログラミング) 工程
  • 8. 従来のV字モデルの欠点要件定義 システムテスト(仕様化) 最初に行った仕様化の正しさは、 外部設計 最後のシステムテストになるまで 結合テスト (システム設計) 分からない例えばプロジェクトの期間が1年だったとすると、 内部設計仕様の正しさが分かるのは1年後になる。 (モジュール設計) 単体テスト終盤で仕様の間違い・漏れ・矛盾が発見された場合の手戻りのコストは極めて甚大となる。 開発実施 (プログラミング) 工程
  • 9. 不具合はいつ発生するのか? 不具合比率不 ソフトウェア開発の具合 約半数の不具合は発 設計工程に起因生 上流工程で埋め込まれたフ 不具合の約半数はテスト工程ェー まで発見されないズ そのため早期の正確な仕様の記述・検証が重要となる2010年版 組込みソフトウェア産業実態調査 不具合発見比率
  • 10. 問題は他にもあるわけで厳密で、間違い、漏れ、抜け、矛盾の無い仕様が必要 But…仕様を記述している自然言語そのものが曖昧なので、正確さを担保することは難しい
  • 11. 自然言語は曖昧だ条件Aが成り立つならば、Xを実行する 条件が成り立たない時の動作はどうなるの?条件AまたはBが成り立つならば、Xを実行する。 成り立たない場合は、Xを実行しない。 AとBが同時に真の場合に条件は成り立つ?成り立たない? 自然言語ではなく、形式的(人工的)な 仕様の記述方法を!
  • 12. 形式手法(Formal Method)• 「形式仕様記述言語」という言語によって仕様 (形式仕様)を記述し、設計や検証を行う手法• 数学ベースの厳密な定義がなされている• 形式仕様は仕様の記述の形式化であって、 プログラムではない(≒実行できない)• ツールのサポートを受けて、仕様のシミュレー ションやコードの生成などが出来る• 様々な言語・ツールが考案されている• Coqもその中の一つ(定理証明支援)
  • 13. メリットとデメリットメリット• 自然言語よりも厳密な仕様の記述が可能• 上流工程で仕様に対する検証が可能。仕様不具合を早期 に発見・修正することが出来る• 仕様に対する『証明(後述)』など、検証能力が高いデメリット• 導入するために、学習コストなどがかかる• 不具合が完全に無くなるわけではない(当たり前)• V&V(Verification and Validation)活動に代わるものではない
  • 14. 自然言語とプログラムの中間? 厳密 プログラム 形式手法による 仕様の記述人間に 人間に分かりにくい 分かり易い 自然言語による 仕様の記述 曖昧
  • 15. 形式手法を取り入れると 要件定義 テストケースの提供 システムテスト (仕様化)・シミュレーション 下流工程に渡す仕様には・形式仕様のテスト(検証) 曖昧さや矛盾などがない 外部設計 テストケースの提供 結合テスト (システム設計) ・シミュレーション ・形式仕様のテスト(検証) テストケースの提供 内部設計 単体テスト (モジュール設計) ・シミュレーション ・形式仕様のテスト(検証) ツールによっては ソースコードを自動 開発実施 生成するものもある (プログラミング) 工程
  • 16. さらに『証明』• テストするだけでは、テストケースから外れたも のについては検証しきれない• コードの網羅性を考慮すると、テスト量は指数的 に増えてしまう• 形式仕様について、完全な検証を行いたい場合 には、テストよりも「証明」を行う• 記述した形式仕様に完全な証明を与えることが できれば、その仕様は「数学的に正しい」ことが 保証される。Good!
  • 17. テストと証明• 証明された仕様から自動生成されたプログラムは、 仕様通りの動作をすることが『証明されて』いる。 Très Bien!• 一般に証明はテストに比べて難しいので、コスト高 になるといわれている• Coqでは、「仕様記述」→「定理や補題の付与」→ 「証明」→「コード生成」 テスト 証明 検証能力 証明に务る 完全 コスト 証明よりかからない かかる 仕様変更 柔軟に対応可能 対応は難しい
  • 18. 前半はここまで• 仕様をどうやって記述するかは非常に大事• 形式手法なら厳密に仕様を書くことが出来るよ!• 形式仕様を証明するとテストよりもスゴイ検証にな るよ!
  • 19. ここからはモリグチがProofCafeにてCoqと出会い、職場に持ち込もうとしたりした話(あるいはコント)です
  • 20. ProofCafe・月に一回、名古屋市内のカフェ「どえりゃあ」にて、 Coqの勉強をしている・内容は主にCPDT(Certified Programming with Dependent Types)を読み進めている・私は6月(第3回)から参加 どえりゃあ 隣でCoqやってるお見合いパーティとか開催されてた
  • 21. どえりゃあ ってこんな場所です定理証明がお邪魔しちゃってますね?→いえ、とっても仲良しです(たぶん)
  • 22. ProofCafeはハードコアでした 「fixpoint」って何ですか? 不動点です 不動点? 解析学のですか? あー、関係はありますが、ここでは 不動点コンビネーターですね あとはパラドキシカル結合子とも言いますね ・・・????
  • 23. 定理証明って面白い! パズルゲームみたい!Tacticを与えて証明のゴールが減ったり増えたりしていくのが楽しい(自分が出来るか否かは別として、)普通のエンジニアが日々作成するプログラムでも、証明って有用なのかな?
  • 24. 証明が使えそうな場面普段の業務におけるプログラミングでも、証明が役に立ちそうな場面は(意外に)多い エンコード f データX データY デコード f 1 x  f 1  f ( x) をいかなる場合でも保証したいここに時間的な制約や、メモリの制約などが加わるので難しくなる
  • 25. 仮に今使ってみたら? 関数型言語分からない 証明って難しそう 仕様が保証されたプログラム 工数増えるよ 間違いなく失敗しますデメリット意識 享受できるメリット
  • 26. もちろんすぐには使えません さすがに、今日や明日から定理証明(Coq)を 仕事で使うには(かなり)無理があるすぐに使えなくても、2~3年後には使えるようになるかもしれない 身近なCoqユーザーを増やそう!職場の近くの席にいる同僚に定理証明の魅力を洗脳啓蒙しました ※業務時間外でしています
  • 27. で、ほら、こんな感じで三段論法なんかが 証明できちゃうんですよ へえ、面白いですね
  • 28. Coqはソースコードを出力できるので、 記述した仕様を証明出来れば、 実装せずに済むんですよ 実装のバグがないなら、 それは素晴らしいですね。 CやC++で出力できますか?
  • 29. いえ、OCamlです OCaml使えません!
  • 30. 洗脳啓蒙難しいです!1. OCamlライクな構文(Gallina)2. Tacticを用いた証明など、普段のプログラミング とのギャップ3. 証明すべき命題を発見する(問題発見)、という 抽象思考4. そもそも数学の教養がない(少なくとも私には)
  • 31. Coqをもっと盛り上げたい• 習得コストや敷居が高く思われる – 関数型言語や数学の教養が求められる – 折しも関数型言語ブーム• Coq習得のモデルケースが見えづらい – どう学習する?独習は難しい? – @maeda_ さんの発表に期待• Coq習得のインセンティブが少ない – 定理証明を導入した成功例などがあれば、興味 を持つ人や企業も増えると思う
  • 32. 最後に• ソフトウェアが今より複雑になり、高品質が求め られるようになるにつれて、形式手法や定理証 明などの力が必要になる予感• 実際に業務に適応できるか否かは、判断しか ねるが、新たな技術を積極的に試すことは、誰 にとっても大事なこと• Coqは触れてて楽しいし、証明出来ると嬉しい
  • 33. おしまいです 次は@maeda_さんです
  • 34. 没ネタ
  • 35. Coqが出来る男はモテるアンケート:コックが出来る男をどう思いますか 約67%の女性が「良い」と回答! 33% 料理が出来る男性は 素敵だと思います 67% 私の夫も 良い0% 悪い コックさんです 無回答 ※モリグチの身近な女性3人調べ
  • 36. 坊や一緒に定理証明をしようよ! 綺麗なtacticsもたんとある!おとーーさん!おとーさん!魔王がCoqを勧めてくるよ! 鬱陶しい怖いよ! 坊やあれは哀れなF#er のざわめきじゃ