経営情報システム学特論2 9．形式仕様記述（4）research.nii.ac.jp/~f-ishikawa/work/UEC-MItoku2/MItoku2... · 2014-12-16 · ※ 数理論理学での用語「モデル」：

SS専攻経営情報システム学講座客員石川冬樹

[email protected]

経営情報システム学特論２９．形式仕様記述（４）

イントロダクション数理論理学とプログラム検証形式仕様記述テスト手法事例・動向紹介

2f-ishikawa @ MI特論2

講義計画

形式手法における探索ベースの手法として，モデル検査とモデル発見を紹介するモデル検査の基礎に関する概観並行プロセスの検査を行うSPINツールモデル発見・有界モデル検査を行うAlloy


本日の内容

探索ベースの手法モデル検査Alloy


目次

状態遷移を網羅的に探索し，検証対象の性質が成り立つかどうかを検証する技術特に並行システムにおいて，特定の実行パスでしか顕在化しない，デッドロックや，排他制御・同期制御の誤りを検出できる

※ 数理論理学での用語「モデル」：ある論理式を真とする解釈（変数の真偽値など）

「モデルであるかどうかを検査する」（状態遷移を表現した「モデル」を検査する，という語源ではない）


モデル検査


モデル検査の基礎：オートマトン

アラームの例

Standby

SensingBeeping

Finished

off stop

eventon

off

shutdown

初期状態

受理状態遷移：状態から状態へラベルでつなぐ

初期状態から受理状態に至るラベル列の例on . event . stop . off . shutdown


モデル検査の基礎：オートマトン

Workx:=1

Done

if x < 3, up, x:=x+1

if x > 1, down, x:=x-1

if x = 1, shutdown

Workx=1

Workx=3

Workx=2

up up

down downDone


モデル検査の基礎：並行動作の合成

A1

doAA2

B1

doBB2

A2/B1 A2/B2

doA doA

doB

doB

A1

doAA2

B1

doBB2

A1/B1 A1/B2

doA doA

doB

doBsync sync

sync

A2/B1 A2/B2


モデル検査の基礎：検証する性質

Reachability ある条件の下ある状況に到達しうる「初期画面に戻る操作の列が常にある」

Safety ある条件の下ある状況に到達することがない「踏切が空いた状態で電車が通過することはない」

Liveness ある条件の下ある状況にいつか必ず到達する「登録をするといつか必ず確認メールが届く」

Deadlock-freeness

デッドロックが起きない

Fairness ある条件の下ある状況が無限回起きる（ない）「ユーザが無数にリクエストを送れば無数に返事が来る（他のユーザ等にブロックされ続けることはない）」

もっともよく用いられている２種類LTL（Linear Temporal Logic）実行を「線」と見て性質を書くCTL（Computational Tree Logic）実行を「木」と見て性質を書く


モデル検査の基礎：時相論理

実行の経過に関する論理式を記述「かつ」「または」「ならば」（命題論理）＋「いつも」「いつか」「までは」・・・

AB

C

A

B

B

C

・・・

A . B . A . B . ...A . B . A . C . ...A . C . B . A . ...

A

すべての（無限長）実行パスに対して何か性質が成り立つかどうかを記述


モデル検査の基礎： LTL

X p（○ p）

次の状態でpが成り立つ（next）

F p（◇ p）

今の状態かそれ以降のどこかでpが成り立つ（finally）

G p（□ p）

今の状態とそれ以降のすべてでpが成り立つ（globally）

p U q 今の状態かそれ以降のどこかでqが成り立ち，それまではずっとpが成り立つ（until）



（各状態で成り立つ，これ以上分解できない基本的な性質に注目している）

S0(¬red, ¬blue)

S1(red, ¬blue)S2(¬red, blue)

S3(red, blue)

S0から始まる実行パスの例（通過する状態の無限列）S0 . S1 . S3 . S0 . S1 . S3 . S0 . S1 . S3 . …

S0 . S2 . S3 . S0 . S1 . S3 . S0 . S2 . S3 . …

S0から始まる実行パスを考えたときの例F (¬ red ∧ blue)「redではなくblueである状態にいつかなる」満たさない実行パスがある（S2を通らずにS1を経由し続けるパス）



S3(red, blue)

S0(¬red, ¬blue)

S1(red, ¬blue) S2(¬red, blue)


モデル検査の基礎：CTL

P

P

P

P

P

P

P

AG P どのパスでも常に

P

P

・・・

P

PP

EG P あるパスでは常に

P

・・・

P

P

AF P どのパスでもいつか

P

P

・・・

EF P あるパスではいつか

P

・・・

全探索を適用しやすい・すべき部分に絞り込み分岐や相互作用の本質に特化し記述する分岐に影響する列挙型のデータ（フラグなど）複数プロセスの切り替え，同期・排他制御，通信エラーが起きるのに十分そうな数で試す（ユーザ数や送受信回数など）数値や集合などデータ構造は原則扱わない

形式仕様やプログラムなどを直接扱う場合外部要素などを単純化したモックに置き換えたり，探索する数値範囲やステップ数などを絞ったり


全探索による検証の考え方


モデル検査の例： SPINツール

#define SIZE 4

byte msg[SIZE];

chan s2r = [2] of {byte};

proctype Sender() {byte i;do:: i == SIZE -> break;:: else -> s2r ! msg[i];

i++;od

}

proctype Receiver() {byte j;byte rmsg;do:: j == SIZE -> break;:: else -> s2r ? rmsg;

assert (rmsg == msg[j]);j++;

od}

proctype Lost() {byte drop;do:: s2r ? drop;

od }

4個のデータを送信してみる

通信チャンネル（有限バッファ長）や送受信に関する語彙を用意

この例は決定的な分岐だが，非決定的な振る舞いを書く

順番通りに来ているかをアサーションで検証（成り立たない）

メッセージを別のプロセスも受信しうるとして通信失敗の可能性を表現

送信

受信

アサーションの検証や，デッドロックの検出それ以上の性質についてはLT）を記述AとBが同時に真になることはない（安全性）

Aが真になった後には必ずBが起きる（活性）

Aが（ブロックされ続けたりせず）何度でも起きうる（ある種の公平性）



[] ! (A && B)

[] ( A => <> B)

[] ! A



検証設定（最短でエラーに到達するパスを探すことも可能）



通信の図示

シミュレーションの種類・ランダム・インタラクティブ・検証結果のログ


モデル検査の例： SMVツール

MODULE mainVAR

cabin : 0 .. 3 ;dir : { up, down }

ASSIGNnext(cabin) := case

dir = up & cabin < 3 : cabin + 1 ;dir = down & cabin > 0 : cabin – 1 ;1 : cabin ;

esacnext(dir) := case

dir = up & cabin = 2 : downdir = down & cabin = 1 : up ;1 : dir ;

esac

次の状態における各変数の値をどう決めるか，という観点で状態遷移記述

単純に上下を行き来するエレベータの動きを表現（実際はともかく3Fまで）


モデル検査の例：UPPAALツール

状態B到達時に時間変数（時間カウンター）tをリセット→ Bを出てCに進むときには時間が3以上経過している

※ テキスト表現もある

共有資源が確保できる（r == 0）ときのみ状態Cに進め，その際には確保（ r := 1 ）

所要時間（のぶれの可能性）も含めて状態遷移を記述


モデル検査の例： ProBツール

Bなどのモデルを受け付けるアニメーター（シミュレーター）兼モデル検査器

検証の結果は下記のいずれかである（全探索した場合）与えたモデルにおいて，検証対象の性質が成り立つことを保証検証対象の性質が成り立たないような実行パスの一例（反例）を提示（最も短いものを探索させることもだいたい可能）状態爆発により検証が未完了


モデル検査の結果

モデル検査の特徴並行システムの設計などにおいて，検証対象とした性質が成り立つ（誤りがない）ことを確信できる実装コードに対するテストでは，様々なタイミングや要因により，問題が発生したりしなかったりするため，テストでは確信が持てない

性質がどうして成り立たなかったのか，のヒントとなる具体的な反例を得ることができる状態爆発に対処するため，検証範囲・モデル化（特に抽象化）・ツール設定などを注意深く検討する必要がある


モデル検査の結果（続）

様々な手法やツール設定により状態削減検証シナリオの設定例：ユーザは２名に限る

様々な抽象化手法例： int型変数 x があり，条件分岐においては

x>0，x=0，x<0 の3つの場合を考えているx = {neg, zero, pos} と列挙型に変更

他にツールの様々な機能もbit単位でうまくメモリに詰め込む工夫を使う対称動作や内部動作等は並び替えを網羅しない（「・・・→Aの内部動作3→Bの内部動作1→・・・」）


モデル検査：状態爆発への対処



x := 0 x := zero

x > 0 -> x == positive ‒>

:: x == neg -> if:: x := neg

x++ :: x := zerofi:: x == zero -> x = pos:: else skip

検証の意味が変わるのが難しい！例：ユーザは２名に限る３名が関わって初めて起きる不整合はない？例： int x を x = {neg, zero, pos} に起きうること・起きえないことが変わらない？



zeroneg posinc inc inc

decdec dec

incdec

-1でも-100でも同じnegであり，1回のincでzeroになれる

この例では抽象版のモデルでしか起きないことがあり，抽象版で起きないことは元のモデルでも起きない

SPINによる設計モデル検証吉岡信和ら，近代科学社，2008

SPINモデル検査中島震，近代科学社，2008

UPPAALによる性能モデル検証長谷川哲夫ら，近代科学社，2012

他にも日本語書籍ありhttp://spinroot.com/spin/whatispin.htmlhttp://www.uppaal.org/


リファレンス：モデル検査

探索ベースの手法モデル検査Alloy


目次

これまで見た手法のいいとこ取りを目指すVDMやBのような強力な記述力集合や関係，命題論理・一階述語論理をベースとし，データ構造やその制約を扱える

モデル検査ツールの使いやすさ「検査」ボタン一発で自動検証を行い，問題があればその反例を得ることができる

さらに，モデル発見とにかく例を出し実感を深めていき，モデルの妥当性を確認しながらインクリメンタルに進められる


Alloyの特徴

グループ，エイリアスの概念を含むアドレス帳グループやエイリアスは他の項目を指すグループに項目を加えるなどの操作を行う

（特に不変条件・事前条件など，仕様項目が一通り厳密，正確に定まっていなくても始めてみる）


Alloy例題：アドレス帳

Group1

Alias4 Address3

Address5

[抽象によるソフトウェア設計－Alloyではじめる形式手法－] の例題アレンジ


Alloy例題：記述例（１ａ）

module intro/AddressBook

/* アドレス帳に含まれる項目 */abstract sig Target {}

/* アドレス */sig Addr extends Target {}

/* アドレス帳に含まれる項目のうち，他項目を指すもの */abstract sig Name extends Target {}

/* エイリアス，グループ */sig Alias, Group extends Name {}

BのSET同様，集合として型を定義（signatureと呼ばれる）

オブジェクト指向も意識Target

Addr NameGroup

Alias

TargetとNameはabstract（直接のインスタンスはない）

extendsで宣言された各signature（集合）は排他的


Alloy例題：記述例（１ａ）

…

pred show1 {}run show1 for 3

pred show2 {#Alias > 1}run show2 for 3

実行（run）は述語に付随して記述する

ここでの実行は，その述語を満たすインスタンス例を（すべて）作ること

要素数が3個以下になる範囲で，エイリアスの個数が2個以上になるインスタンスを作る（右の4個）

要素数が3個以下になる範囲で例を作る

基本的に書きかけでも「動かせる」


Alloy例題：記述例（１ｂ）

…

/* アドレス帳 */sig Book {names: set Name,contains: names -> some Target}

…

pred show1 {}run show1 for 3 but 1 Book

先の記述に定義を追加

複数のNameと，包含関係（保持しているNameから１個以上のTarget）を持つ

これだけでは自由にリンクが貼られた例が出てしまう

Bookだけは１個，他要素3個でインスタンス生成


Alloy例題：記述例（１ｃ）

…

/* アドレス帳 */sig Book {names: set Name,contains: names -> some Target}{all a : Alias | one a.containsno n : names | n in n.^contains}

…

直後に書くと，任意のBookに対する(all)制約となる

任意のAliasに対し，containsを適用して得られる（リンク先の）Targetはちょうど１つ

Names内のどのNameにおいても，containsを1回以上適用して得られる（1回以上リンクをたどった先の）Targetの集合に自分自身は含まれない


Alloy例題：記述例（１ｃ）

…

pred show2 ( b : Book ){#Alias > 0Alias in b.names#Group > 0Group in b.names#Addr > 1}run show2 for 5 but 1 Book

より意味のありそうな例を作ってみる

生成するインスタンスにおいて，

AliasとGroupはそれぞれ１個以上存在する

それらは作られたBookのnamesに含まれる（部分集合である）


Alloy例題：記述例（２ａ）

…

pred add ( b, b' : Book, n : Name, a : Addr ) {not n -> a in b.containsb'.contains = b.contains + n -> ab'.names = b.names}

…

操作を表現する「述語」を定義

2つのBookがあったときに，片方がadd操作の実行前の状態，もう片方が実行後の状態を表すとするためには，どのような性質が成り立てばよいか？という述語

・事前条件を表す条件

・事後条件を表す条件



…

pred show1 ( b, b' : Book ) {#(b.contains) = 1one n : Name | one a : Addr | add[b, b', n, a] }run show1 for 5 but 2 Book

…

リンクをちょうど1つ持つbと，そのbにリンクを1つ追加したb‘とが存在するとき，trueとなる述語

2つのBookを生成するようにして実行



…

pred show2 ( b0, b1, b2 : Book ) {one n : Name | one a : Addr | add[b0, b1, n, a]andone n : Name | one a : Addr | add[b1, b2, n, a]}run show2 for 5 but 3 Book

…

b0に対してあるリンクを追加したb1，さらにリンクを追加したb2とが存在すると，trueとなる述語

3つのBookを生成するようにして実行


Alloy例題：記述例（２ｂ）

…

pred add ( b, b' : Book, n : Name, a : Addr ) {/* not n -> a in b.contains */b'.contains = b.contains + n -> ab'.names = b.names}

pred del ( b, b' : Book, n : Name, a : Addr ) {n -> a in b.containsb'.contains = b.contains - n -> ab'.names = b.names}

…

addから事前条件を抜いてみる

同様にdel操作を表す述語を定義


Alloy例題：記述例（２ｂ）

…

assert delUndoesAdd{all b0, b1, b2 : Book, n : Name, a : Addr |add [b0, b1, n, a] and del [b1, b2, n, a] implies b0.contains = b2.contains}check delUndoesAdd for 5

検査対象のアサーションを定義同じリンクをaddしてdelすると，元に戻る

特定の要素個数内で網羅的に検査（有界モデル検査）

（事前条件を消したので）すでに含まれているリンクをaddしてdelした場合，元には戻らないというインスタンスがある（「不具合」と思うかは解釈次第だが）

集合と関係を書いていくだけデータを表現するも，実行パスを表現するも，自由（記法としては同じ）実行パスをどのように表現するかも，自由（VDM風でも，SPIN風でも）

例：先ほど3個のbook間に対して制約を与えることにより，2ステップのadd操作が現れるインスタンスを作る述語を作ったn個のbookの間において，n-1ステップのadd操作またはdel操作が現れるようにすれば，「実行」も表現できる


Alloyによる計算機のモデル化


参考：実行の経過の表現例（３）

open util/ordering [Time]

…

sig Time{state: Book}

fact traces {all t : Time - last | let t' = next [t] | one n : Name, a : Addr |addAddr[t.state, t'.state, n, a] or delAddr[t.state, t'.state, n, a]

}

…

ライブラリを使うことにより，Timeのインスタンスに順序が付いて，nextという関係でたどれるようにする

各Timeには，その時間での実行状態（Book）がひもづいている

最後以外の時間とその次の時間では，状態がaddまたはdelでつながっているようにする

Alloy記述はSATに変換され，SATソルバーが裏で動いているSAT： satisfiability problem論理式全体の値を真にするような、真偽値の組み合わせは存在するか？近年SATソルバーはかなり性能が上がっている特定個数に絞って，制約を満たす全インスタンスを生成，例示可能有界モデル検査のためには，assertionの否定をとって，満たさない例の生成を試みればよい


補足： SATソルバー

抽象によるソフトウェア設計－Alloyではじめる形式手法Daniel. Jacksonら，オーム社，2011

形式手法入門―ロジックによるソフトウェア設計中島震，オーム社，2012

http://alloy.mit.edu/community/


リファレンス：Alloy

探索ベースの手法効率的な探索アルゴリズムを用い，状態遷移（の特定部分）を網羅的に探索するアサーションなどが成り立たなかった場合，その判例を示すことができる状態爆発の問題があるため，システムにおける本質的な要素のみを抜き出し，抽象化するなどの工夫が必要となる

次回ここまでのまとめと補足


今回のまとめ

Documents

経営情報システム学特論2 9．形式仕様記述（4）research.nii.ac.jp/~f-ishikawa/work/UEC-MItoku2/MItoku2... · 2014-12-16 · ※ 数理論理学での用語「モデル」：