D-Case 構文 41

D-CaseはAssurance Caseの記法のひとつである、GSN (Goal Structuring Notation) を拡張した構 文を標準構文として用いる。通常の自然言語や、表形式、Agdaなどの形式言語での記述は、標準構文へ の変換が定義されていればD-Case構文に準拠しているとする。D-Caseの基本的な例を図4-5に示す。

図4-5はウエブサーバにおける応答遅延障害に対処できているという主張を、障害をモニタリングでき ることと、障害が検知されたとき、障害が復旧できることに分けて議論している。障害復旧には、D-Script を用いるとしている。

図4-5: D-Caseの例

D-CaseはGSN Community Standardをベースに、DEOSで考えられてきた拡張を行った表記法を用 いる。GSN Community Standardには多くの曖昧、未定義な部分がある。D-Case仕様は、GSN

Community Standardをベースに、曖昧、未定義な部分を補完しながら、DEOSでの研究成果を加え、

D-Case委員会で策定中であり、D-Case Editor、D-Case Weaverにおいて参照実装中である。

A. ノードの種類

D-Caseのノードは、GSNで既に定義されているノードに加え、D-Caseで拡張されたノードよりなる。

各ノードは文章の他に、責任属性など種々の属性が定義されている。

図4-6: GSNノードとD-Case拡張ノード GSNノード

・ ゴール (Goal)

対象システムに対して、議論すべき命題である。例えば「システムはディペンダブルである」とか「シ ステムは適切な安全性をみたす」などである。

・ 証拠 (Evidence)

詳細化されたゴールを最終的に保証するものである。例えばテストや形式手法による検証結果などで ある。

・ 戦略 (Strategy)

ゴールが満たされることを、サブゴールに分割して詳細化するときの議論の仕方である。例えば、「シ ステムは安全である」というゴールに対して、現時点で識別されているハザードに対処できているこ とによって議論したいとき、戦略ノードとして「識別されたハザードごとに場合分け」を用いると、

例えばひとつのサブゴールは「システムはハザードXに対処できる」となる。

・ 前提 (Context)

ゴールや戦略を議論するとき、その前提となる情報である。例えば、運用環境や、システムのスコー プ、あるいは「識別されたハザードのリスト」などである。システムの安全性などを議論する場合、

その環境や運用条件を明確にすることが大切である。

・ 正当化 (Justification) 前提のサブクラスである。

・ 仮定 (Assumption)

前提のサブクラスである。

・ 未達成 (Undeveloped)

ゴールが達成されていることを示す十分な議論や証拠がないときに使う。

・ モジュール (Module)

他のモジュールのD-Caseを参照するためのノードである。モジュールには、説明責任属性として、

担当者名などの情報が付与される。

・ 契約 (Contract)

モジュール間の関係を表すためのノードである。GSN Community Standardにおいて、定義が特に 曖昧であるため、現在仕様を検討中である。

D-Case拡張ノード

・ モニタ (Monitor)

システムのランタイム時の情報をもとにした証拠である。例えばウエブサーバの応答速度のログ結果 などである。証拠ノードのサブクラスである。

・ パラメタ (Parameter)

D-Caseパターンにおけるパラメタ設定のためのノードである。前提ノードのサブクラスである。

・ アクション (Action)

システムのランタイム時における、システム障害対応に関する証拠である。例えばウエブサーバの応 答遅延障害に対処するための D-Script の実行トレース結果などである。証拠ノードのサブクラスで ある。

・ 外部接続 (External)

外部組織により管理されているモジュールである。モジュールノードのサブクラスである。

・ 責任 (Responsibility¹)

責任属性が異なるモジュールの関係を説明するためのノードである。モジュール間のリンク上で定義 される。

B. ノードのつなげ方、リンクの種類

・ ゴールは戦略を通して分解される

1 説明責任は、DEOSではAccountabilityの訳語として使われる。Responsibilityとの違いはDEOSプロジェクトにおいても多くの時間を割 いて議論した。ここでは、システム全体に対し、ディペンダブルであることの（境界のない）説明責任としてAccountabilityを当て、システム 内のサブシステムやステークホルダ間の２項関係において、一方が与えられた（境界のある）責務を、他方に対して果たすことにResponsibility の訳語を当てた。責任ノードは後者の２項関係を表すノードであるため、Responsibilityの訳語を当てた。システム間のすべてのステークホル ダの責任(Responsibility)関係を満たすならば、システム全体の説明責任（Accountability）につながる（オープンな環境では境界がないので、

それだけではないが）とDEOSで議論した。

図4-7: ゴールの分解の仕方

・ D-Caseのリーフは、証拠、未達成、モジュール、モニタ、アクション、外部接続のいずれかである

・ 前提は、ゴール、もしくは戦略につなげられる。

・ リンクは２種類ある。

 支援リンク (SupportedBy): ゴールから戦略、戦略からゴール、ゴールから証拠、ゴールからモ ニタ、ゴールから外部接続、ゴールから未達成、戦略から未達成。

図4-8: 支援リンク

 前提リンク (InContextOf): ゴールから前提、戦略から前提をつなぐ。

図4-9: 前提リンク

C. Inter-Module 関係

D-Caseモジュールには一つのトップゴールを持つD-Caseが管理される。モジュール間の関係を表す

Inter-Module関係（2重矢印で表す）が定義される。Inter-Module 関係は、モジュール間のノードや

D-Caseの部分への参照関係により定義される。例として、図4-10は、LANデバイスシステムのD-Case

モジュールの参照関係を表したものである。

図4-10: Inter-Module Relationの例

d*は、Inter-Moduleを基本として定義される。Moduleごとに責任者を割り当て、Module間の

D-Caseの参照関係により、責任者間の責任関係を与える。例を考える。Module 「Dependability」の

責任者がYutaka Matsunoであり、Module 「Security」の責任者がShuichiro Yamamotoであったと

する。Module 「Dependability」はあるシステムのディペンダビリティに関するD-Caseが管理されて いるとする。ディペンダビリティの議論にはセキュリティの議論が含まれうる。セキュリティの議論を 行うため、Module 「Security」を参照したとする。このとき、二つのモジュールの責任者が異なるため、

責任関係が生じる。下図のRで示される説明責任ノードに責任関係を記述する。

図4-11: d*フレームワークの基本

4.3.2 D-Case 記述法

D-Case記述はシステムのライフサイクルを通じて、様々なドキュメントを用いて、様々なステークホ

ルダが関わりながら行われる。Assurance Caseの記述プロセスの研究開発は行われているが、広く実用 化されたプロセスはまだない。本節では[1]で提案した記述法を紹介する。

1. システムライフサイクルを整理し、フェーズの入力、出力ドキュメントをまとめる 2. 入力、出力ドキュメントを分類する

3. トップゴールを置く: 「システムはディペンダブルである」

4. ディペンダビリティ要求、環境情報、語彙定義を前提としてトップゴールにおく 5. 大まかにD-Case の構造を考える

6. 必要なドキュメントを前提として置く

7. ドキュメントからD-Case のサブツリーを作る

8. サブツリーができていない部分を典型的な議論構造を使って作る 9. 上記を必要なだけ繰り返す

それぞれのステップを解説する。

ステップ１ システムライフサイクルを整理し、それぞれのフェーズの入力、出力ドキュメントをまと める。

D-Caseはシステムのライフサイクルにおいて生成されるドキュメントをもとに作る。その理由は、

D-Caseは従来のシステム開発、運用で生成されるドキュメント群を置き換えるものではなく、基本的に

はそれらドキュメントを用いて、システムがディペンダブルであることを示すためのドキュメントであ るからである（Assurance Caseを記述することは、従来のリスク分析や、要求分析手法を置き換えるも のではないと[2]で論じられている）。まずD-Caseを記述し、D-Caseで要求されるドキュメントを生成 するための活動をシステムライフサイクルで行うなどの手法の開発も今後考えられる。

簡単な例を図4-12に示す。

図4-12: システムライフサイクルの例

システムのライフサイクルが上図のように定義されていたとき、それぞれのフェーズでの入出力ドキ ュメントは例えば表4-1のようになる。

表4-1: システムライフサイクルの入出力ドキュメントの例

D-Caseはこれらのドキュメントをもとに生成される。実際のシステムライフサイクルでは、当然もっ

と多くのドキュメントがある。それらのドキュメントの中から、システムのディペンダビリティに関わ るドキュメントを選択し、D-Caseを記述する(すべてのドキュメントがD-Caseに関係する可能性もある)。

ステップ２ ライフサイクルの入出力ドキュメントを分類する

ライフサイクルの入出力ドキュメントが、D-Case、すなわちシステムのディペンダビリティの議論に どのように関係するのか考える。これまでの経験から、D-Caseに関係するドキュメントの種類は以下の ようなものがあると考える。

（１） 規格。ISO 26262、 ISO/IEC 12207など、システムが適合することを要求される国際規格など。

（２） リスク分析結果。システムのサービス継続を脅かすリスクを解析した結果。ハザード解析、故障 木解析(Fault Tree Analysis)の結果など。

（３） ディペンダビリティ要求。例えば99.999 %の可用性などの要求。ディペンダビリティ要求はシス テムごとに異なり、明確にする必要がある。上の例では、利用者インタビュー文書、要求定義文 書が相当する。

（４） システムのライフサイクルに関するドキュメント。ステップ１にあるような、システムのライフ サイクルドキュメントは、システムのディペンダビリティを議論する上で重要である。

（５） システムアーキテクチャモデル。システムのアーキテクチャは、UMLなどを用いて記述される。

システムのコンポーネントがそれぞれどのようにシステムのディペンダビリティに寄与するか議 論する必要があるときに参照する。上の例では、アーキテクチャ仕様書が相当する。

（６） 運用情報。障害はシステムの運用時に起こる。そのため、システムがどのように運用されるかは 非常に重要である。システムのログ情報は、システムの現時点でのディペンダビリティの状態を 知るために重要である。上の例では運用定義書、運用ログが相当する。

（７） 環境情報。システムが置かれた環境を特定しないと、システムのディペンダビリティは議論でき ない。

（８） テスト、検証結果。これらは、D-Caseにおいて、証拠ノードにおいて参照される。システムのデ ィペンダビリティを最終的に保証するものである。

（９） プログラムコード。特に、障害対応を行うプログラムコードは、システムのディペンダビリティ