「形式的検証」の版間の差分

提供: miniwiki
移動先:案内検索
(1版 をインポートしました)
(産業での応用)
 
32行目: 32行目:
  
 
検証プロセスには静的部分と動的部分がある。例えばソフトウェア製品なら、ソースコードの検査ができるし(静的)、特定のテスト条件で実行させることもできる(動的)。妥当性検証(Validation)は動的にしかできない。すなわち、製品を典型的局面で利用してみたり、一般的でない局面で利用してみたりする(すなわち、それはあらゆる[[ユースケース]]に対して満足できる動作をするか、である)。
 
検証プロセスには静的部分と動的部分がある。例えばソフトウェア製品なら、ソースコードの検査ができるし(静的)、特定のテスト条件で実行させることもできる(動的)。妥当性検証(Validation)は動的にしかできない。すなわち、製品を典型的局面で利用してみたり、一般的でない局面で利用してみたりする(すなわち、それはあらゆる[[ユースケース]]に対して満足できる動作をするか、である)。
 
== 産業での応用 ==
 
設計の複雑さが増すにつれ、形式的検証技法の重要性は特にハードウェア業界で増している<ref>{{Cite journal|doi=10.1109/LICS.2003.1210044|title=Formal verification at Intel|year=2003|last1=Harrison|first1=J.|pages=45–54}}</ref><ref>[http://portal.acm.org/citation.cfm?id=800667 Formal verification of a real-time hardware design]. Portal.acm.org (1983-06-27). Retrieved on 2011-04-30.</ref>。コンポーネント間の潜在的な微妙な相互作用により、シミュレーションだけで考えられる組合せをすべて調べるのは難しくなってきている。ハードウェア設計の重要な面は自動化証明技法に適しており、形式的検証の導入が容易で生産的である<ref>[http://www.cl.cam.ac.uk/~jrh13/slides/types-04sep99/slides1.pdf Formal Verification in Industry]</ref>。
 
 
2011年現在、いくつかの[[オペレーティングシステム]]が形式的検証を採用している。
 
* [[L4マイクロカーネルファミリー|Embedded L4 microkernel]]([[:en:NICTA|NICTA]])<ref name="Ganssle">[http://www.embedded.com/columns/breakpoint/220900551 "A new OS has been proven to be correct using mathematical proofs. The cost: astronomical."] by Jack Ganssle</ref>
 
* [[:en:Integrity (operating system)|Integrity]]([[:en:Green Hills Software|Green Hills Software]])<ref name="Ganssle"/>
 
* [[PikeOS]]([[:en:SYSGO|SYSGO]])<ref>Christoph Baumann, Bernhard Beckert, Holger Blasum, and Thorsten Bormer [http://www-wjp.cs.uni-saarland.de/publikationen/Ba10EW.pdf Ingredients of Operating System Correctness? Lessons Learned in the Formal Verification of PikeOS]</ref>
 
  
 
== 脚注 ==
 
== 脚注 ==

2018/9/29/ (土) 22:59時点における最新版

形式的検証(けいしきてきけんしょう)とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである。

完全な形式的検証は、システムにプログラミングの誤りがないことを保証する既知の唯一の方法である。
ACMシンポジウムで発表された論文の要約から[1]

使い方

形式的検証の適用例としては、内部にメモリを持つ暗号回路、組み合わせ回路、デジタル回路などのシステム、ソースコードで表現されるソフトウェアがある。

これらのシステムの検証は、システムを抽象化した数理モデル上で行われ、その数理モデルと実際のシステムの性質は一致している。使用される数理モデルとしては、有限状態機械ラベル付き遷移系ペトリネットtimed automatahybrid automataプロセス計算プログラミング言語の形式意味論操作的意味論表示的意味論公理的意味論)、ホーア論理などがある。

形式的検証の手法

形式的検証の手法は大きく2つに分類される。

第一の手法はモデル検査と呼ばれる。これは数理モデルの体系的かつ徹底的な検証を意味する(有限なモデルでのみ可能だが、無限の状態を持つモデルであっても抽象化によって有限な表現が可能であれば検証可能である)。一般にモデル内の全状態と全遷移の検証を含み、演算時間を減らすために領域固有の抽象化技法などを駆使して効率化を図る。実装技法には状態空間列挙法English版、抽象状態空間列挙法、抽象解釈記号シミュレーションEnglish版、abstraction refinment などがある。検証される特性(プロパティ)は時相論理で記述され、線形時相論理 (LTL) や計算木論理 (CTL) が使われる。

第二の手法は論理的推論である。一般に HOLACL2IsabelleCoq といった定理証明ソフトウェアを使い、システムに関して形式的な推論を行う。この手法は完全自動化されていないのが一般的で、ユーザーの対象システムについての理解に応じて行われる。最近では、Perfect Developer や Escher C Verifier といったツールが証明の完全自動化を試みている。

線形論理時相論理などの非古典論理は、モデル検査だけでなく論理的推論でも使われる。

ソフトウェアの形式的検証

ソフトウェアの形式的検証のための論理推論はさらに以下のように分類される。

  • 1970年代のより古典的手法では、まずコードを普通に書き、続いてのステップで正しいことを検証する。
  • 依存型プログラミングEnglish版では、関数の型がその関数の仕様(の一部)を含み、コードの型チェックによって仕様に対する正しさが保証される。完全な依存型プログラミング言語は第一の手法を特殊ケースとしてサポートする。

それとは相補的な若干異なる手法としてプログラム導出がある。その場合、正しさを保持したステップを踏んで関数仕様から効率的コードを生成する。例として Bird-Meertens Formalism (BMF) があり、"correctness by construction" の別の形態と見ることもできる。

Validation と Verification

検証(Verification)は製品が目的に適合しているかどうかをテストする観点の1つである。妥当性検証(Validation)はそれを補完する観点と言える。この両者を合わせて検証プロセス全体を V & V と呼ぶこともある。

  • Validation: 「我々は正しい製品を作っているか?」すなわち、その製品はユーザーが本当に必要とすることを行っているか?
  • Verification: 「我々は製品を正しく作っているか?」すなわち、その製品は仕様通りに作られているか?

検証プロセスには静的部分と動的部分がある。例えばソフトウェア製品なら、ソースコードの検査ができるし(静的)、特定のテスト条件で実行させることもできる(動的)。妥当性検証(Validation)は動的にしかできない。すなわち、製品を典型的局面で利用してみたり、一般的でない局面で利用してみたりする(すなわち、それはあらゆるユースケースに対して満足できる動作をするか、である)。

脚注

  1. Gerwin Klein; Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, Thomas Sewell, Harvey Tuch, Simon Winwood et al. “seL4: Formal Verification of an OS Kernel (paper submitted to 22nd ACM Symposium on Operating Systems Principles, October 2009)”. . 2011閲覧.

関連項目