NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第136回 保証ケース作成支援ツールの概要国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 山本修一郎

国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授
(前NTTデータ フェロー システム科学研究所長)山本 修一郎

本連載第135回では、実践的な要求のまとめ方であるCROS法の適用例として、RISE研究[1,2]で開発している保証ケース作成支援ツールの要求のまとめ方を紹介した。今回は、保証ケース作成支援ツールの機能を紹介しよう。まず、統一的保証ケース作成支援ツールについて述べる。次いで、このツールに対するシステム構成図から保証ケースを生成できることを紹介する。

経緯

筆者らは、これまで、DFD(Data Flow Diagram)、use case diagram、 equence diagramなどに対して、個別に保証ケースパターンを提案してきた[3,4,5]。これらのパターンの数は、対象分解、参照モデル分解、条件分解、推論分解、証拠分解、再分解からなる6分類49個である。

エンタープライズアーキテクチャ記述言語ArchiMate[22,23]では、ビジネスアーキテクチャ、アプリケーションアーキテクチャ、テクノロジーアーキテクチャという3種類のアーキテクチャモデルを記述できる。これらの3種類のアーキテクチャに対しても個別に保証ケースパターンを考案することができる。しかし、統一的ではないので、保証ケースパターン開発の効率が悪いという問題がある。このため、本稿で紹介する手法を用いて、ArchiMateの3種類のアーキテクチャモデルに対して、統一的に保証ケースを作成できる保証ケースパターンを提案した[6,7]。

以下では、まず、保証ケースのパターンアプローチの研究動向について述べる。次に、統一的保証ケースで用いる基本パターンを説明する。さらに、提案手法の適用事例について紹介する。

研究動向

保証ケースを作成するためにGoal Structuring Notation (GSN)が提案されている[8][9][10]。しかしGSNでは上位の主張を分解するアプローチに関する明確なガイドラインがないので、どのように主張を分解すればよいかわからないという問題がある。主張を分解するためにBloomfieldとBishopによって提案されたパターンには、アーキテクチャ、機能、特性などがある[11]。アーキテクチャ分解パターンを適用する場合、システムアーキテクチャに基づくシステムのそれぞれの構成要素がシステムのディペンダビリティ要求を満たす必要がある。DespotouとKellyは、安全性ケースをより明快にするモジュール化手法を提案した[12]。HaugeとStolen[13]は、核エネルギーコントロールドメインのため、安全性ケースアプローチに基づくパターンを提案した。Wardzinski[14]は、事故の危険順序の仮定に基づく車両安全ドメインを保証するためのアプローチを提案した。Alexander, Kelly, Kurd, McDermid[15]によって、デザインパターンのフォーマットに基づく議論パターンの書式が提案されている。この論文では故障モード分析に基づく安全議論パターンを提示している。

GraydonとKelly[16]は、議論パターンによって通信障害管理について議論する方法を調査している。Ruizらは、保証ケースリポジトリを使用することにより、保証ケースを再利用することを提案している[17]。DenneyとPai[18]は、安全性ケースパターンのための形式手法を提案した。

彼らは、(1)Instantiateparameters(2)Resolve choices(3)Resolve multiplicities(4)Unfold loopsのようにパターンの改善方法を形式化して、パラメータ化された議論パターンの改善ルールを示している。保証ケースは、議論パターンを扱うために拡張されている。HawkinsらがGSNパターンを用いたモデルに基づく保証ケース作成手法を提案している[19]。彼らはスクリプト言語で生成手順を記述している。Gallinaらがプロダクトライン開発手法とGSN拡張からなる安全性ケースライン手法によりISO 26262準拠の安全性ケースを作成する方法を提案している[20]。Lin[21]ではどのようにして安全性ケースパターンを製造業者の開発プロセスに、安全性ケース作成のための再利用戦略として導入するかについて議論している。これらの手法ではGSNパターンを再利用して保証ケースを作成するために、特定の適応方式を仮定している。

保証ケースの基本パターン

統一的保証ケース作成支援手法で用いる保証ケースの基本パターンには、アーキテクチャ分解パターン、特性分解パターン、リスク分解パターンがある[7]。

(1)アーキテクチャ分解パターン

保証ケースのアーキテクチャ分解パターンでは、システムが特性を満たすことを、アーキテクチャとして定義されるシステム構成に基づいて保証する。システム構成では、システムの構成要素とその関係が定義されるので、図1のように、「システムが特性を満たしている」という主張を「システムの構成要素が特性を満たしている」ことと「システムの構成要素間の関係が特性を満たしている」という2つの下位の主張に分解することによって、保証ケースを作成できる。この2つの下位の主張はさらに、構成要素と関係要素によって分解される。

図1 アーキテクチャ分解パターン

図1 アーキテクチャ分解パターン(クリックで拡大)

(2)特性分解パターン

特性分解パターンでは、「システムが特性を満たしている」という主張を特性の構成要素に従って分解する。たとえば、ディペンダビリティ特性には、可用性、信頼性、安全性、一貫性、機密性、保守性がある。したがって、「システムがディペンダビリティ特性を満たしている」という主張を図2のように、6個の下位の主張に分解できる。ここで、ディペンダビリティ特性には、可用性、信頼性、安全性、一貫性、機密性、保守性がある[19]。

図2 特性分解パターンの例

図2 特性分解パターンの例(クリックで拡大)

(3)リスク分解パターン

安全性やセキュリティなどの特性については、対象がこれらの特性を満たすことを直接説明することは難しい。この場合、「対象が特性を満たしている」という主張を、特性リスクの定義に基づいて、「対象が特性リスクに対策している」という下位の主張に分解することで説明できる(図3)。ここで、特性リスクが複数ある場合には、特性リスクごとに下位の主張を作成する。

図3 リスク対策分解パターン

図3 リスク対策分解パターン(クリックで拡大)



続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。

第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。