成功した形式手法導入調査例の分析と発見 - IPA · 様記述言語を利用する! • レベル3：厳密な仕様を検証する! • レベル4：完全に形式的に開発する（抽象的

成功した形式手法導入調査例の分析と発見

〜どのように形式手法は導入されたか？〜

酒匂寛 Designers’ Den Corp. [email protected]

2012/11/15 形式手法の導入 © 2012, Sako Hiroshi 1

自己紹介

•  1980 年代 –  COBOL とワークステーションの時代 –  汎用機・オフコンを用いた COBOL 開発 –  ワークステーション上での開発環境の開発

•  1990 年代 –  大規模プロジェクトとオブジェクト指向の時代 –  2000人月超の大規模プロジェクトをOOで –  組込み機器のソフトウェアをフレームワーク化

•  2000 年代 –  モデリングと形式手法の時代 –  証券、組込み機器に形式手法を適用 –  領域・課題・仕様・設計・検証のフレームワーク化

2 2012/11/15 形式手法の導入 © 2012, Sako Hiroshi

証券業務(TradeOne) FeliCa Firmware

内容

•  形式手法とは •  事例ピックアップ •  事例分析を通して観察された点 •  学習リソース •  まとめ


形式手法とは


形式手法とは？

•  銀の弾丸ではない •  数学でもない（類似した記法は使う） •  ただ開発対象をより厳密に書き留め、解析可

能にするための単なる「工学的」手法である •  世界中で少しずつ採用が進んでいる

– 欧州：一番伝統もありリソースもある – 米国：モデル検査に強みがある – 日本：世界的成功事例（FeliCa）を擁する


厳密さのレベル

•  レベル１：離散数学の概念や記法を用いる •  レベル２：適切なツールの支援と共に形式仕

様記述言語を利用する •  レベル３：厳密な仕様を検証する •  レベル４：完全に形式的に開発する（抽象的

な仕様を詳細化して行く）

PETER GORM LARSEN教授 ([email protected]) による


このレベルまでは比較的容易 FeliCa などの事例もここに相当する

形式手法の色々

•  モデルベースアプローチ(VDM, Z, B) •  代数アプローチ(Act One, Larch, OBJ) •  プロセス代数 (CSP, CCS) •  論理アプローチ (RTL, TLA) •  リアクティブアプローチ (Petri-‐nets, SDL, SAO) •  複合アプローチ： eg. RAISE (VDM + CSP) and LOTOS (Act One + CCS)

今回の話題で取り上げる手法形式仕様記述を行い検証産業界での導入に馴染みやすい


簡単な例：「N営業日後」の仕様


指定した日付（平日）から休日を除いた N 日後の日付を返す関数の「仕様」は？

public N営業日後 : 日付 * nat -‐> 日付 N営業日後(起算日, 日数) == is not yet specified -‐-‐ アルゴリズムは未定 pre not 休日(起算日) and 日数 > 0 post let days = 全日付(起算日, RESULT) in card 平日集合 (days) -‐ 1 = 日数;

事後条件に注目。RESULT（関数の戻り値）そのものが式の一部に使われている。RESULT の求め方はここには示されていないが、RESULT がどのような性質を満たすべきかはきちんと示されている。

事例ピックアップ


調査対象事例

組み込み FeliCa, BPS1000紙幣検査機

航空管制 SHOLIS, iFACTS

金融 TradeOne

言語処理オランダ軍メッセージ分析, CAVA

機密情報処理 MULTOS CA, Tokeneer

電子商取引オランダ花市場


以下の形式手法導入プロジェクトに関して実担当者にインタビューを行った詳細な調査報告書は IPA/SEC のホームページからダウンロード可能になる予定

FeliCa ファームウェア (1) 問題領域：IC カードファームウェア仕様記述言語：VDM++

工夫効果

VDM仕様を開発チームで共有される辞書と位置づけた

開発対象への共通理解が得られた

VDM仕様のテスト、品質管理チームによるテストケースレビューをおこなった

製品の信頼性が非常に高くなった

VDMのトレーニングとして１週間のコースと現場でのVDM専門家のコンサルテーションを受けた

仕様の読み書き


FeliCa フォアームウェア (1) -‐ プロジェクトの流れ

形式手法の導入 © 2012, Sako Hiroshi 2012/11/15

FeliCaファームウェア(2) 仕様記述言語: VDM++

工夫効果

スタイルを操作的記述から関数的記述へ変更した

可読性の向上

VDM仕様から決定表を導出したテストケース作成時の仕様の可読性の向上

命名規則により隠蔽関数を区別した

仕様と設計を分離することができた

(1)に引き続きVDM専門家のコンサルテーションを受けている

仕様に関する工程の改善


FeliCa ファームウェア (2)


オランダ軍メッセージ分析問題領域：オランダ軍メッセージデータマイニング仕様記述言語： VDM-‐SL, 自然言語

工夫効果

定型化された要求記述仕様とテスト仕様をそれぞれ独立して策定

VDM仕様のアニメーション実行

仕様の実行で得た知見を使って自然言語で効果的な顧客レビュー

VDM仕様からのコード自動生成

仕様記述の工数を確保しながら全体の工期を圧縮


DOD - プロジェクトの流れ

2012/11/15 形式手法の導入 © 2012, Sako Hiroshi

オランダ軍メッセージ分析：コスト配分


実装テスト

実装テスト分析・設計

伝統的手法:

VDMTools®:

Cost

分析・設計

900 2000 700

1200 500 600

0% 64% 100%

単位は人時

MULTOS CA マスターカード認証サーバ仕様記述言語：Z記法(+SPARK)、UML、自然言語 ITSEC E6セキュリティ基準(形式的検証済み設計、テスト)

工夫効果

コンテキスト図、クラス図、構造化操作定義、英語からZ仕様を作成し、CSP,　SPARKで設計/実装

従来手法による顧客との対話と形式手法による仕様記述と設計、実装を両立

SPARKによりバッファオーバランや実行時例外等の検証、静的分析

信頼性の向上


MULTOS – プロジェクトの流れ


iFACTS 英国航空管制システム

安全性、スケジュール厳守(ロンドンオリンピック) 顧客もZ記法を学習し、開発に参加

読み書き

人数 75名 11名

職種開発者、ドメイン専門家、航空管制官

開発者

コース 3日間 3日間

実地訓練 1週間 3ヶ月


iFACTS


Tokeneer 米国国家安全保障庁(NSA)の生体認証システム

仕様記述言語： Z記法(+SPARK) Common Criteria EAL5(準形式的設計、及びテスト) 工夫効果

顧客がZ記法を学習し、Z仕様をレビュー

遠隔地にいる顧客による正確なレビュー

１週間のコース、Z専門家がアシストしイディオム等の解説

仕様の読み

全ての開発リソースが公開されている

厳密な手法を用いた開発経験の共有


Tokeneer


TradeOne 証券バックオフィスパッケージ

仕様記述言語: VDM++

工夫効果

ユースケース仕様の回帰テスト、仕様を繰り返し改善

システムの信頼性が向上した

第二期では日本語の識別子を採用

仕様の生産性と可読性が大幅に向上した

ドメインフレームワークの採用

仕様と設計の追跡性が向上し、ユースケースの誤りに素早く対応できた


TradeOne


事例分析を通して観察された点


成功プロジェクト共通の属性

•  ヒアリング調査の結果から、どのプロジェクトも共通して、厳

密な仕様を、プロジェクト全体から参照される辞書あるいは

情報のハブとして用いていることが明らかとなった。

•  ヒアリング調査したプロジェクトでは、「厳密な仕様」の取りま

とめに形式手法を用いることにより、検証済の記述単位と記

述範囲を明確化することができていた。

•  仕様の一部を、形式手法以外の表現手段（日本語による文

章、多様な図や表、等）として抽出することで、議論したりレ

ビューしたりという作業が大幅に容易化されていた。


要求

仕様

設計妥当性を検証正当性を検証

検証検証検証

テストケーステストケース

システムテスト

単体・結合テスト

テストケース

ユーザーテスト

利用者の確認精度向上早期の検証によるコスト減

下流工程への精度の高い指示効果的なテストケース作成

厳密な仕様の位置付け


FeliCa フォアームウェア (1) -‐ プロジェクトの流れ

形式手法の導入 © 2012, Sako Hiroshi 2012/11/15

再掲

FeliCa (１)から FeliCa (２)へ厳密な仕様記述の改善例

考察：ラベル付き条件によるレビュー容易性の評価

cases false : (パケットサイズ十分？ ("サービス数”)), (サービス数範囲内？ (cmd_pkt, cmnd_pkt_st))) -> <ERROR_NO_RESPONSE>, others -> <SUCCESS> end;

-- パケットの長さがサービス数まで存在する十分なパケットであること packet_len_of_service_num >= 9 and -- パケットにおいて指定されたサービス数が規定の範囲内であること 1 <= service_num and service_num <= 32

private サービス数範囲内？ : PACKET_DATA * PACKET_STRUCTURE -> bool サービス数範囲内？(cmnd_pkt, cmnd_pkt_st) == let CmndPkt = パケット要素取得(cmnd_pkt, cmnd_pkt_st), num = hd CmndPkt(“サービス数") in 1 <= num and num <= 32;

ラベル付き条件を用いない場合

ラベル付き条件を用いた場合

左上の「ラベル付き条件を用

いない場合」は FeliCa(1) の記述方式の一部である。日

本語による注釈が読みやす

さの向上のために添えられ

ていた。 FeliCa(2) では更に読みやす

さを向上させることを狙い、

左下の「ラベル付き条件を用

いた場合」のような工夫を

行った。述語に日本語識別子を用い

たり、記述形式を工夫したり

することによって、レビューの

しやすさを向上させた。


FeliCa (２)

形式仕様からのテストケース導出

「ラベル付き条件」の形式で

書かれた仕様から、体系的

に左のようなデシジョンテー

ブルを抽出し、テストケース

を設計できるような仕掛けを

考えた。レビューがしやすくなり、機械

的なテストケースのチェック

ツールも用意された。

ディシジョンテーブルの活用

条件同値分割境界値 TC1 TC2 TC3 TC4

実行可能モード？ TRUE 0..2 Y Y Y

FALSE 3 Y

パケットサイズ十分？ TRUE 10 Y Y Y

FALSE 9 Y

サービス数範囲内？ TRUE 1..32 Y Y

N

FALSE 0, 33 N Y

結果正常応答 Y

応答なしエラー Y

応答ありエラー Y Y テストケースの網羅性を視覚的に確認することができる。レビューが容易になる。


形式仕様の適用箇所

•  形式手法はどの段階にも適用可能 o  仕様、設計、実装、検証のどの段階でも利用されている

o  成功したプロジェクトは皆、形式記述がその前後の段階や成果物とどのように対応しているかが明確にされている

•  特定の特性全域を記述

o  成功したプロジェクトはプロジェクト内で着目したある特性に関しては全面的に選んだ形式記述を適用している

o  複数の作業者が協調するためには必須


自然言語(日本語)記述との共存

•  開発チーム内での扱い o  形式記述と非形式記述（自然言語による説明や図など）

を併記・併用することにより、読み易さと厳密さを共存させることができる

o  両者の間の食い違いを取り除き易いように適度な粒度（例えば１ページ程度）の単位で構成する

•  開発チームと外部との関係での扱い o  外部を形式手法の読み手として訓練する方法

o  外部を形式手法の読み手としては訓練せず、形式手法を使う技術者が様々な形に変換して外部に提示する方法


調査事例における「顧客」との対話手段

形式仕様を利用形式仕様を利用せず

国内（*FeliCa は API 文書を形式仕様から半自動生成）

FeliCa(1) FeliCa(2) TradeOne

海外 iFACTS Tokeneer

SHOLIS オランダ軍メッセージ分析 MULTOS CA BPS1000 CAVA オランダ花市場


このプロジェクトを受託した Altran Praxsis という会社は、顧客との契約も形式仕様の項目ベースで行い、問題が生じたときにそれがどちらの責任かが逐一明確になるようになっている

iFacts:テストケースの記述自然言語 + 形式記述


Test Design

厳密な仕様策定手順の一例

•  要求記述の内容のうち、問題領域自身の性質（システムが変えることのできない部分）と、構築対象（システムが影響を及ぼす部分）への記述を区別する（à 領域資産化）

•  要求記述を読み、用語を切り出す •  クラスもしくは型と、関数もしくは操作の候補を見つける •  クラスの構造（型、属性、関連）に関する概略を書く •  関数／操作に関する概略を書く（シグニチャを決める） •  要求記述から不変な性質を抽出して定義する •  事前条件、事後条件もしくは定義本体を記入することによって、関

数／操作定義を完成させる、必要ならば型定義を変更する •  作成された仕様のモデルが利用者の期待や、要求中に現れる項

目や制約を満たしているかどうかをアニメーション等を通して検証する

•  以上のステップを必要なだけ繰り返す


「問題領域」の語彙の充実厳密さ ((機械処理、テスト可能))

貸出機能 : 図書館型 * 書籍型 * 利用者型 -‐> 図書館型

貸出機能(lib, book, user) == is not yet specified pre book in set dom lib.登録書籍 -‐-‐ 書籍が登録書籍であること

and user in set lib.登録利用者 -‐-‐ 利用者が登録利用者であること

and 書籍貸出可能数(lib, book) > 0 -‐-‐ 書籍に貸し出し用の余裕があること

and (user in set dom lib.貸出中 and (card lib.貸出中(user) < 3))

-‐-‐ 利用者の利用制限冊数を超えていないこと

post -‐-‐ 指定された書籍が「貸出中」に登録されてい

る

(user in set dom RESULT.貸出中) and (book in set RESULT.貸出中(user));

厳密さ＋読み易さ

貸出機能 : 図書館型 * 書籍型 * 利用者型 -‐> 図書館型

貸出機能(lib, book, user) == is not yet specified pre 登録済み書籍(lib, book) and 登録済み利用者(lib, user) and 貸出可能書籍(lib, book) and 利用者貸出制限数内(lib, user) post 書籍貸出中(RESULT, book, user);


問題領域の語彙を充実させることによって仕様の見通しが良くなる。一部は仕様部品資産として残る

既存資産の進化例

Level 0 現状 Level 1 現状記述 Level 2 現状改善 Level 3 次世代準備

（既存の仕様書）階層構造を持つ機種共通部分と独自部分

に分かれる

（仕様の回帰テストにより）既存の日本語仕様書との一致を保証済み

全体像を把握しやすい

仕様の十分な抽象化

検索性の向上ある関心に特化した

閲覧性がある

日本語仕様書 Ver. A

日本語仕様書 Ver. A

日本語仕様書 Ver. B

形式仕様書 Ver. X

形式仕様書 Ver. Y

日本語仕様書 Ver. C

形式仕様書 Ver. Z

日本語仕様書との対応が明確で読みやすい記述

リファクタリングフィードバック


階層記述の例


記述階層名記述目的記述例

検証シナリオ階層仕様アニメーションを行うための検証シナリオ（テストケースなど）を定義した階層

(例えば非接触ICカードの場合) 個別コマンド検証シナリオなど

機能仕様階層特定の応用に対する機能仕様を定義する階層

カード操作コマンド仕様など

問題領域データ階層問題領域に特有の共通データ等を定義した階層

具体的なファイル構造など

問題領域階層共通問題領域で繰り返し利用される関数や不変条件などを定義する階層

カードファイルシステム、データパケットの変換など

共通領域階層特定の問題領域に依存しない階層。ネットワーク（数学的な意味で）や、組合せアルゴリズム、文字列や数値に関する共通処理などがここで記述される

階層型データ処理など

学習リソース


利用できる様々なリソース

•  様々な実践ノウハウの提供

•  実践ノウハウの共有

•  VDM, B, SPIN, etc …

•  基本的な情報

書籍ツール

コンサルタン

ト

コミュニティ


VDM研究会 SEA SIGFM FM Europe

バートランド・メイヤー氏による、「オブジェクト指向の原理とモデル」を徹底的に考察した入門書。「契約による設計」に関する解説もオリジナル故にしっかりとしている。


契約による設計

形式仕様記述で用いられる事前条件、事後条件、不変条件などについて、日本語で詳しく説明された書籍の代表。ソフトウェア工学の学習書籍としても読み応えあり。


要求と仕様の大切さ

ソフトウェア要求と仕様　―　実践、原理、偏見の辞典マイケルジャクソン (著), 玉井哲雄 (訳), 酒匂寛 (訳) 本体価格： \3,570 単行本: 267 p ; サイズ(cm): 21 x 15 出版社: 新紀元社 ; ISBN: 4775302876 ; (2004/04)

ソフトウェア開発を「記述」の体系として捉え、それにまつわる様々な話題を取り扱った本

形式仕様記述


ソフトウェア開発のモデル化技法岩波書店

VDM-‐SL の教科書。形式仕様を用いたモデル化の基本を解説

形式仕様記述

VDM++によるオブジェクト指向システムの高品質設計と検証（翔泳社）ジョン・フィッツジェラルド、ピーター・ゴルム・ラーセン、ポール・マッカージー、ニコ・プラット、マーセル・バーホフ (著), 酒匂寛 (翻訳)

45

VDM++を用いて、形式モデリングの基礎と応用を学習します。他の形式手法にも応用可能。


モデル検査


SPINモデル検査―検証モデリング技法中島震近代科学社 2008年

モデル検査ツール SPIN を用いたモデル検査入門書

まとめ


形式仕様導入のための留意点

•  厳密な仕様記述をプロジェクト情報のハブとする –  常に頼れる検証済みの情報の起点として利用できるようにす

ることが必要 –  記述対象を選んだらそれに関しては完全に記述する

•  複数の手法を組み合わせる –  仕様記述以外にも適切な手法を組み合わせることにより、厳密

な仕様記述の効果が増加する

•  適切なツールを選択/調整/作成する –  単体のツールだけではなく、必要に応じた組合せが必要 –  形式的記述を核に形式的ではない記述との相互変換を行う

•  積極的な事例開示を行う –  積極的な事例開示によって皆の知恵を集めやすい土壌を作る


形式手法とは

•  銀の弾丸ではない •  数学でもない（類似した記法は使う） •  ただ開発対象をより厳密に書き留め、解析可

能にするための単なる「工学的」手法である •  世界中で少しずつ採用が進んでいる

– 欧州：一番伝統もありリソースもある – 米国：モデル検査に強みがある – 日本：世界的成功事例（FeliCa）を擁する


再掲

明日から始めるには？

•  現状の棚卸をする – プロセスとドキュメントを整理する

•  形式仕様、形式手法適用が相応しい部分/対象を選ぶ – いくつか候補を選び、記述を用いたプロセスを試行す

る。同時にコアメンバーを訓練する •  可能ならば「新しいプロジェクト」の上流から適用

してみる – コンサルタントのアドバイスとレビューが初期にはとて

も有効


まず専門家のアドバイスを

避けるべきこと

•  闇雲な適用 – 「すべて」を記述することは労多くして実り無し – 適切な「性質」に着目しそれに関しては完全に記

述する

•  我流の記述 – 一度は専門家のレビューを受けた方がよい – 特に what と how の混同による記述を詳細に行

うと保守の難しい仕様を生み出しがちになる



Questions?

ご清聴有難うございました

Documents

成功した形式手法導入調査例の 分析と発見 - IPA · 様記述言語を利用する! • レベル3：厳密な仕様を検証する! • レベル4：完全に形式的に開発する（抽象的

成功した形式手法導入調査例の分析と発見 - IPA · 様記述言語を利用する! • レベル3：厳密な仕様を検証する! • レベル4：完全に形式的に開発する（抽象的