■ 1. 概要と目的
- 背景: 要求・仕様・設計・テストケースの定義は人によって異なり統一されていない
- 目的: 理論に裏付けられた統一的で明確な定義を提示し成果物の品質向上とコミュニケーションエラーの削減を図る
- 目的: 成果物を機械的に処理可能にすることで少ない労力で目的を達成できるようにする
- 理論的基盤: Jackson の要求の考え方・Hoare の CSP の安定失敗モデル・Meyer の DbC の定義を実務向けにアレンジしたもの
■ 2. 基礎概念
- イベント:
- 状態遷移の引き金となるもの
- UIイベント・時間経過・通信・内部イベントτ の4種類がある
- 内部イベント:
- 状態機械の外から観測できず発生を制御できない特別なイベント
- タイムアウトやシステム内の通信のような隠蔽されたイベントをτで表現する
- 同期イベント:
- 複数の状態機械が1つのイベントで同時に状態遷移する場合のイベント
- τは同期イベントにはできない
- 典型例はクライアントとサーバー間の通信・ユーザーとシステム間のUI操作
- 並行合成:
- 2つの状態機械と同期イベントの集合から1つの大きな状態機械を作る操作
- 同期イベントの場合は両方の状態機械が同時に遷移できる場合のみ遷移可能
- 非同期イベントの場合は一方のみが遷移できれば遷移可能
- トレース:
- 初期状態から連続的に遷移可能なイベントの列のうちτを取り除いたもの
- 状態機械が出せるすべてのトレースを集めた集合をトレース集合という
- 安定状態:
- その状態からτで遷移できない状態
- 失敗:
- 安定状態に至るトレースとその安定状態で拒否されるイベントの集合の組
- 状態機械のもつすべての失敗を集めた集合を失敗集合という
■ 3. 詳細化の連鎖
- 上流の成果物から下流にいくにしたがって実装するシステムの姿は徐々に明らかになる
- 機能要求では振る舞いの一部分だけ定義する
- 仕様では機能要求で言及されていなかった部分の振る舞いを定義し実装に自由度を残す
- 実装では許された自由度の範囲内で正常系・異常系の振る舞いを定義する
- 詳細化の順序: 機能要求 → トップレベル仕様 → コンポーネント仕様 → コンポーネント実装
- 非機能要求は遷移にかかる時間や使用性などの定量指標によって実装を制約する
■ 4. 機能要求
- 定義: 失敗集合やトレース集合の満たすべき性質の定義
- 悪い失敗:
- 失敗集合に含まれていてはいけない失敗
- あるトレースの後に実行できるイベントを定めることに相当する
- 失敗集合に悪い失敗が含まれなければいいことを起こせることをいえる
- 悪いトレース:
- トレース集合に含まれていてはいけないトレース
- 悪いトレースがトレース集合に含まれなければ悪いことが起こらないことをいえる
- 機能要求の時点では言及されていないトレースや失敗がどうなっているかはわからない
- 情報セキュリティの性質のうち安全性に関するものは非機能要求ではなく機能要求に含まれる
■ 5. 非機能要求
- 定義: 量的な指標でしか記述できない性質（真偽で決定できない）の定義
- 遷移にかかる時間・使用性などが該当する
- 使用性の例: 主要なユーザーストーリーの達成に必要なUIイベント数や視線の動きの総量
■ 6. トップレベルの仕様
- 定義: トレース集合と失敗集合の組（安定失敗方式）
- 状態機械で構成することが一般的であり直接書き下すことは困難
- 仕様の時点では実装に自由度を残す非決定性が残っている以外は振る舞いがわかる
- 状態機械の記法:
- 状態には状態変数を記述する
- 遷移には「イベント [ガード] / 事後条件」の3つを記述する（ガードは真なら省略可）
- ガード: 状態遷移できる条件でイベントと遷移前の状態変数を参照できる
- 事後条件: 状態遷移前後の状態変数の関係を定義し遷移後の状態変数には ' をつける
- 画面表示を伴う場合は各状態における画面の画像を返す関数（画面表示の条件）が加わる
- シーケンス図による代替: QCDの面で状態機械が許容できない場合にシーケンス図で記述することがあるがトレース集合を誤解するリスクがある
■ 7. 機能要求と仕様の関係
- トップレベル仕様の失敗集合とトレース集合は機能要求を満たさなければならない
- 満たすべき条件1: 悪い失敗が失敗集合に含まれていない
- 満たすべき条件2: 悪いトレースがトレース集合に含まれていない
- 機能要求を満たす仕様は複数存在し最も優れたものを選ぶことが仕様記述の本質
- 選択基準1: 非機能要求を高く満たすこと
- 選択基準2: 実装コストの安い実装を採用できるように自由度が高いこと
- 仕様インスペクション: 仕様のトレース集合に悪いトレースや悪い失敗が含まれないことを確認する
■ 8. 設計
- 定義: トップレベルの仕様を人間の理解しやすい小さな状態機械（コンポーネント仕様）に分解する作業およびその成果物
- 設計の時点でもトレースは実装に自由度を残してよいが仕様で許容された自由度を超えてはならない
- コンポーネント仕様がトップレベル仕様を満たす条件:
- 並行合成後のコンポーネント仕様のトレース集合 ⊆ 仕様のトレース集合
- 並行合成後のコンポーネント仕様の失敗集合 ⊆ 仕様の失敗集合
- 仕様を満たす設計は複数存在し将来にわたっての経済性が最も高いものを選ぶことが設計の本質
■ 9. API設計書
- 定義: コンポーネント間の同期イベントの形式とリクエストとレスポンスの関係をシグネチャと事前条件と事後条件の組で定義したもの
- コンポーネント仕様の部分的な別表現であり状態遷移図から機械的に導出できる
- 事前条件: APIに規定の振る舞いを期待していい入力と通信前の状態の条件（満たされない場合の振る舞いは問われない）
- 事後条件: リクエストとレスポンスの間の関係とAPI実行前後の状態の間の関係
■ 10. 実装
- 定義: トップレベルの仕様またはコンポーネント仕様を満たす実行可能な状態機械またはそれを作成する作業
- 仕様またはコンポーネント仕様の許した自由度の中で振る舞いを1つ選ぶ（疑似乱数生成器等による非決定性は許容）
- コンポーネント実装がコンポーネント仕様を満たす条件:
- コンポーネント実装のトレース集合 ⊆ コンポーネント仕様のトレース集合
- コンポーネント実装の失敗集合 ⊆ コンポーネント仕様の失敗集合
- 実装からは遷移にかかる時間や計算機資源にかかる負荷などの統計データを得られ非機能要求を満たさなければならない
■ 11. テストケースと検証
- テストケースの定義: トレースと期待結果の組
- 悪い失敗のサンプルに対する期待結果は受理
- 悪いトレースのサンプルに対する期待結果は拒否
- トレース集合や失敗集合は巨大でありすべての要素を調べきることはできない
- 検証の本質: 与えられたリソースと時間の制約の中で最もリスクを下げられるサンプルを選ぶこと
- 探索的テスト: 実装のトレース集合のサンプルがすべて仕様のトレース集合に入ることを確認するテスト（計画主導のテストケースとは対偶の関係）
■ 12. 成果物間の論理的保証
- 機能要求をトップレベル仕様が満たしかつ並行合成したコンポーネント仕様がトップレベル仕様を満たせば並行合成したコンポーネント仕様は機能要求を満たす
- 並行合成したコンポーネント仕様がトップレベル仕様を満たしかつすべてのコンポーネント実装がそれぞれのコンポーネント仕様を満たせば並行合成したコンポーネント実装もトップレベル仕様を満たす