実装前に AI と合意せよ！Quint で形式仕様読解入門

TAKT にいれた形式仕様について、かなりいい感じに思うので記事にします。 形式仕様そのものになじみのない方も多いと思うので、そこから始めます。 形式仕様とは 自然言語で書かれた仕様書は読む人によって解釈が揺れます。 同じ文章を読んでも、人によって思い浮かべる挙動が違うことがあります。 この食い違いを防ぐ手段が形式仕様です。 システムの振る舞いや満たすべき性質を、数学的に意味の定まった記法で書いた仕様のことで、記法の意味が一つに決まるため、書いた人と読む人で解釈が分かれません。 形式仕様の記法には専用の検証器が用意されているものがあります。 検証器を使うと、書いた仕様に論理的な矛盾がないかを自動で確かめられます。 守りたい性質を書いておけば、その性質が破れる操作手順が存在しないかも機械的に調べられます。 状態の遷移を網羅的に探索して性質を確かめるこの調べ方を、モデル検査と呼びます。 人の手

[TakayukiN627]

形式手法は高い信頼性が求められる現場で古くから使われてきました。ただ、仕様を書いて維持するコストが高く　～　AI が書く側を引き受けるなら、仕様を書くコストは大きく下がります。

[yarumato]

“この記事は Quint をまったく知らないプログラマが、Quint を読み解けるようにするために書きました。　（実例）　コードにみえるので素直に読めそうなものですが、手続き型言語のノリで追っていくと迷子になります”

[mkusaka]

Quintの形式仕様を「宣言・モデル・性質」3層で読み、AIと合意する方法を解説。verfiy/weakFair例も紹介。