enhancement cente r information-technology …...2014/05/28 · 35 レベル4：

Information-technology Promotion Agency, Japan

S o f t w a r e R e l i a b i l i t yEn h an c emen t Cen t er

Copyright © 2013,2014 IPA, All Rights Reserved Software Reliability Enhancement Center

実務家のための形式手法

SEC-FM1-A1-01


厳密な仕様記述入門


仕様の位置付け

形式仕様記述手法を用いて

2Copyright © 2013,2014 IPA, All Rights Reserved Software Reliability Enhancement Center

仕様の位置付け(このモジュールについて)

ソフトウェア開発における「仕様」の位置付けを理解することを目的とする。仕様は単体で完成するものではなく、先行する「課題」（要求と領域）ならびに、後続の「設計」などとの関連で定義される。

事前知識・経験旧来のソフトウェア開発に対する問題意識(ソフトウェア開発の実経験があるとより好ましい)

形式手法の知識・スキルは前提としない

学習目標ソフトウェア開発における「仕様」の占める位置付けを「課題」「設計」との相互関係として理解する。

仕様は単なる開発の通過地点ではなく、プロジェクトの要となり、繰り返し妥当性確認（Validation）と正当性検証（Verification）により参照される対象であることを理解する。

厳密な仕様記述が開発工程全体に及ぼす影響に対して理解する

厳密な仕様記述の適用レベルについて理解する

SEC-FM1-A1-01


仕様の位置付け (このモジュールについて)

主な学習項目1. 課題・仕様・設計

2. 事例でみる仕様の位置付け

3. 厳密な仕様記述の適用レベル

SEC-FM1-A1-01


１．課題・仕様・設計

SEC-FM1-A1-01


システム開発の３つの視点

課題利用者の視点

現実世界にどのような問題を抱えており、そのうちどの部分をシステム化して解決したいと思っているのか

入力：問題領域知識（事実）＋業務要求（願望）

仕様利用者と開発者の視点

上で挙げられた課題の解決を、どのようなシステムで支援するのか

入力：課題＋システム要求

設計開発者の視点

要求されるシステムの仕様をどのように設計すべきか

入力：仕様＋最新構築技術

SEC-FM1-A1-01


課題・仕様・設計

課題は複数の機能仕様に写像される

経路探索仕様経路探索仕様

道案内をする

経路探索仕様

経路探索設計

目的地への誘導どのような入力（位置、選択条件）で、どのような出力（経路）を得たいのか

どのような計算方法を用いて、求められる結果を得るのか

課題

仕様

設計

複数の仕様をどのように組み合わせて目的を達成するか

SEC-FM1-A1-01


課題・仕様・設計

課題：解きたい問題、叶えたい希望の明確化

例：「複数の子供をそれぞれ満足させながらお菓子を配りたい」

仕様：問題解決の定式化

例：子供たちの満足度の偏差値の差異を x 以内に抑えつつ、満足度の平均値を y 以上に

設計：定式化の実現

例：実際の分配方法を、定式化の結果を満たすように計算

SEC-FM1-A1-01

ここはかなりうまく出来るようになってきた

ここはまだまだ発展途上

仕様記述

設計記述

問題記述

世界の定式化

テスト証明自動生成


仕様（書）の位置付け

「仕様」は課題と設計をつなぐもの

言い換えれば「問題の解決」が「問題の解法」にどのように結び付けられるかを記述するもの

「問題の解決」とは：

どのような条件のもとでどのような効果・状態が得られたり維持されたりすれば、問題が解消されたといえるかを規定

利用者にとっての「価値」

「問題の解法」とは：

与えられた材料で指定された効果、状態を創出するために具体的に行うべき手順

SEC-FM1-A1-01


課題・仕様・設計の要素

課題仕様設計

価値

【願望】要求、提案、改善、企画、欲望、創造、課題、etc...

【事実】法令、理論、原則、外部、人間、etc...

制約、条件、性質、情報、機能、状態、時間、体験、 etc ...

アーキテクチャ、プロトコル、データ構造、データ管理、アルゴリズム、実装言語、利用者インタラクションデザイン、etc...

「仕様」は「課題」と「設計」の接点

既にあるものこれから創るもの

SEC-FM1-A1-01


【課題への注目】要求は「そこにあるもの」か？

要求が役割としての発注者の頭の中に既にあるわけではありません。しばしば「要求を発注者がはっきりさせてくれないから仕様が決まらない」という不満が聞かれますが、そもそも要求とははっきりしないものなのです。ごく一部の要求だけが（とりあえず）はっきりしています、例えば「列車の予約が行えるシステムを作りたい」など。

しかしその先に一歩踏み込むと、「列車」とは何か「予約」とは何かすら厳密に考えると曖昧であることに気付かされることがあります。

SEC-FM1-A1-01


【課題への注目】安定しているもの、創りあげるもの

課題（要求）を検討していく際には比較的安定している環境（事実、物理法則、法律、既存システムなど）と不安定な「これから創りあげるもの（サービスや製品）」の関係の整理が大切です。

検討の過程ではありとあらゆる仮説が登場し、仮の仕様と組み合わさって、課題に対する仮想的な確認が行われます。ともすると開発の中身ばかりに目が向いてしまいそれが課題に対して満足できるものなのかの検討がおろそかになったりします。

SEC-FM1-A1-01


仕様が曖昧であることの弊害

SEC-FM1-A1-01

既存の設計「書」（eg. UML+自然言語）

課題

改善項目

機能希望

外部制約：物流

外部制約：期限

外部制約：予算

既存の仕様「書」（eg.自然言語）

ここが不完全であると＊記述の一貫性、完全性の検証が困難＊仕様アニメーションによる検証が困難

仕様１（曖昧）

仕様２（矛盾）

仕様３（未記述）

仕様４（個人メモ）

画面イメージ

操作環境アーキテクチャ

コンポーネント配置

モジュール機能設計１

モジュール機能設計２

ユースケース

仕様記述が不完全であると＊「課題」との間の追跡性を辿るのが困難

仕様記述が不完全であると＊課題が変更されたときに「仕様」を介して設計へと正しく反映されているかの確認が困難＊意図した「仕様」に「設計」が沿っているかの検証が困難


仕様の追跡性

SEC-FM1-A1-01

課題仕様設計

記述される要素間の対応関係をはっきりさせるためには、記述を厳密に行い、かつ機械による管理を行いやすいようにすることが有効

各記述の要素を可能な限り独立に追跡できることが大切


現在の記述のメディア

SEC-FM1-A1-01

課題

仕様

設計

妥当性を確認正当性を検証

日本語エクセルパワーポイント …

日本語UML(UseCase)…

UMLプログラム言語…

例えば・・・


検証の視点

SEC-FM1-A1-01

課題

仕様

設計

妥当性を確認正当性を検証

日本語日本語UML

UMLプログラム言語

②それぞれの記述が一貫していて矛盾がない

③上流からの入力に対して正しい

①要求にモレがない


検証のための厳密な記述

１：要求にモレがない

欠けている要素を見つける自動化は困難で問題領域の専門家の知恵を集めるしかない

対称性、一覧性に優れた厳密な記述が必要

２：それぞれの記述が一貫していて矛盾がない

記述内部の矛盾を見つける文法的に正しく意味的に矛盾していないかどうか

厳密な記述が必要

３：上流からの入力に対して正しい

記述「間」の整合性を調べる上流の記述からテストケースを導き、下流の記述をテストする

あるいは上流から下流に向けて証明と詳細化を繰り返す

厳密な記述が必要

SEC-FM1-A1-01


記述とテスト

SEC-FM1-A1-01

課題

仕様

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

検証検証検証

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

システムテスト

単体・結合テスト

テストケース

ユーザーテスト


厳密な仕様記述の効果

SEC-FM1-A1-01

課題

仕様

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

検証検証検証

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

システムテスト

単体・結合テスト

テストケース

ユーザーテスト

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

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

VPPUnit

VDM++pre/post/invariant

UML図他生成ドキュメント

VDM++pre/post/invariant


厳密な仕様記述を実現する形式仕様とは

SEC-FM1-A1-01

仕様を厳密な構文と意味をもつ手段で記述し、検証、妥当性確認、文書化、設計といった開発活動の品質を向上させる手法

例として取り上げる VDM は有力な形式仕様記述言語の一つである

開発現場での品質の向上には言語やツールが大きな役割を果たす。


仕様の品質基準 (IEEE830-1998)

SEC-FM1-A1-01

特性説明

正当性ソフトウェアが持つべきすべての要求が含まれており、それ

以外の要素は含まれていない

無曖昧性個々の要求の意味が明確

完全性全ての必要な要求が含まれている

全ての入力と状態に対する応答の定義が含まれている

用語及び図表の説明が含まれている

一貫性要求間で矛盾がないこと

順位付け要求が重要性や安定性に関して順位付けられている

検証容易性全ての要求が有限のコストで検証可能

修正容易性容易かつ完全に一貫性を保って要求の変更を行うことができ

る

追跡性要求の根拠が明確で開発工程全体で参照できること

いずれの特性も、仕様を厳密化することで（特に形式手法を採用することで）向上させることができる


参考：「なぜ品質の追求は割に合うのか？」

欠陥の多いソフトは高くつき、ときには人命をも脅かす

ソフトウェア技術者は人間であり、それゆえ欠陥を生む

欠陥発見と修復のコストは、開発の進展に伴い等比級数的に増大するレビュー：インスペクション：テスト = 3 : 25 : 1400 (min/error)

プログラムを開発した技術者こそが、最も欠陥の発見と修復に優れている

効果的な欠陥除去手法には、特別な訓練が必要である

あなたがソフトウェア品質を管理せずして、だれがするのか？

SEC-FM1-A1-01

W.ハンフリー「ソフトウェアでビジネスに勝つ」（Winning with Software）第４章より

高品質の仕事は時間と費用を節約する高品質の仕事はより予測しやすい


2. 事例でみる仕様の位置付け

SEC-FM1-A1-01


仕様記述事例：FeliCa ファームウェア

問題領域：IC カードファームウェア

仕様記述言語：VDM++

SEC-FM1-A1-01

工夫効果

形式仕様記述言語VDMによる記述を開発チームで共有される辞書と位置づけた

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

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

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

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

仕様の読み書き


FeliCa ファームウェア - プロジェクトの流れ

SEC-FM1-A1-01


仕様記述事例：オランダ軍メッセージ分析

問題領域：オランダ軍メッセージデータマイニング

仕様記述言語： VDM-SL, 自然言語

SEC-FM1-A1-01

工夫効果

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

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

VDM仕様からのコード自動生成仕様記述の工数を確保しながら全体の工期を圧縮


オランダ軍メッセージ分析- プロジェクトの流れ

SEC-FM1-A1-0SEC-FM1-A1-01


参考：鉄道システムの仕様記述

OMRON+AIST

システム事例

タイプ／個数1. 曖昧さ／19 箇所2. 矛盾／3 箇所3. 場合わけの漏れ／7 箇所

SEC-FM1-A1-01


プロジェクト情報ハブとしての厳密な仕様

SEC-FM1-A1-01

成功したプロジェクトでは、厳密な仕様がプロジェクト全工程から活用される「情報ハブ」の役割を果たしていることが多い


厳密な仕様定義の手順（例）

SEC-FM1-A1-01


３．厳密な仕様記述の適用レベル

SEC-FM1-A1-01


厳密な仕様記述（形式仕様記述）の適用レベル

レベル１：離散数学の概念や記法を用いる

レベル２：適切なツールの支援と共に形式仕様記述言語を利用する

レベル３：厳密な仕様を検証する

レベル４：完全に形式的に開発する（抽象的な仕様を詳細化して行く）

SEC-FM1-A1-01

Peter Gorm Larsen 博士の分類による


レベル１：離散数学の概念や記法を用いる

離散数学の集合、列、写像などの要素と、∀とか∃を用いた論理式で日本語では曖昧になりがちな表現を正確に表現することが可能になる

注意しなければならないのは、数学の概念や記法を用いても、「数学」を対象にしているわけではないということ。あくまでも記法を借用して、その操作を便利に使っているだけである

SEC-FM1-A1-01


レベル２：適切なツールの支援と共に形式仕様記述言語を利用する

レベル１の段階では、個々の文章の一部を数学的な記法を用いて厳密化しただけだが、これだけでは仕様をひとかたまりのものとして扱うことは困難である。個別の文章が単独に厳密化していたとしても、集めてみると様々な相互矛盾や、粒度の違いなどが発見される可能性がある。

形式仕様記述言語を用いて表現した仕様はツールによる「構文検査」「型検査」などを通して基本的な記述の一貫性を保証することが可能である。その上で多くの形式仕様記述言語処理系は仕様をまとめ構造化するための様々な仕掛けを提供している。

SEC-FM1-A1-01


レベル３：厳密な仕様を検証する

レベル２の段階では、まだ形式的に記述されたとは言え、検証については構文レベルや型レベルの整合性を静的に検査するものにとどまっている。これは人間の目視による検証よりは間違いの少ないものになるものの、定義した仕様の実際の振る舞いの検証についてはそれだけでは不足している。

仕様の検証には既に説明したように大きく分けて二通りの方法がある。（１）仕様に対してさまざまなテストケースを適用しその振る舞いを計算して期待値と比べる方法（所謂テスト）と、

（２）仕様の定義そのものから想定されている性質がいつでも成り立つことを論理的に導き出す証明の採用である。

SEC-FM1-A1-01


レベル４：完全に形式的に開発する（抽象的な仕様を詳細化していく）

レベル３までの適用で形式仕様記述言語を用いた厳密な記述を行い、従来のテスト技法を援用した検証を行なっているので、詳細な設計段階に入る以前に仕様そのものを検証し問題点を抽出することが可能になる。一般的には上流で発見された問題ほど低コストで修正が可能なので、仕様段階での検証は大きな意味を持つ。

一方テスト技法を用いた検証だけでは心許ないという考え方の場合には、定義された仕様の振る舞いが、その要請に適合しているのか、振る舞いを詳細化して設計へと書き換えて行く個々の段階が正当に行われているかをより厳密に検証できる手段を採用することになる。これは仕様記述を使った「証明」を行うことによって実現される。

証明を行なって正しさを検証した場合、機能に関する「テスト」を行う必要はない。なぜならそれは既に証明済だからである。

SEC-FM1-A1-01


サマリー

SEC-FM1-A1-01


サマリー

主に以下を学習課題・仕様・設計の関連と仕様の役割

事例でみる仕様の位置付け

厳密な仕様記述の適用レベル

SEC-FM1-A1-01

enhancement cente r information-technology …...2014/05/28 · 35 レベル4：

Documents