以下、本発明を実施するための形態について説明する。
<DEOSプロセス>
図1は、本発明の実施の形態において想定するDEOSプロセス100の概要を示す図である。オープンシステムディペンダビリティ、すなわち、機能、構造、システム境界が時間とともに変化し続けるシステムに対するディペンダビリティを実現するためには、反復的プロセス(iterative process)としてのアプローチが必須である。この反復的プロセスは、目的(objectives)や環境の変化(environmental change)に対してシステムを継続的に変更していくためのサイクル(変化対応サイクル100−01)と、障害に対して迅速に対応するためのサイクル(障害対応サイクル100−02)とを備えている必要がある。両サイクルにおいて、合意記述データベース(agreement description database)110が参照または更新される。なお、以下では、合意記述データベース110を「D−ADD」と短縮して呼称する場合がある。
変化対応(change accommodation)サイクル100−01は、上流プロセスにおける対象システムのオープンシステムディペンダビリティを担保するために必要とされるプロセスからなるサイクルである。この変化対応サイクル100−01は、合意形成(consensus building)プロセス100−03と、開発(development)プロセス100−04と、説明責任遂行(accountability achievement)プロセス100−05の3つのプロセスを定義している。
障害対応(failure response)サイクル100−02は、対象システムの運用時に必要とされるプロセスからなるサイクルである。この障害対応サイクル100−02は、障害対応プロセス100−06と、説明責任遂行プロセス100−05の2つのプロセスを定義している。普段は、両サイクルとも対象システムは通常運用状態(ordinary operation)100−07にある。
対象システムのディペンダビリティに関する利害関係者を、DEOSプロセス100においては「ステークホルダ」と呼ぶ。ステークホルダとしては、1)サービス・製品の利用者(顧客、社会的インフラの場合は社会全体)、2)サービス・製品の提供者(事業主)、3)システム提供者(設計開発者、保守運用者、ハードウェア供給者)、4)サービス・製品認可者(規制監督官庁)等を想定するが、これに限定されるものではない。
ステークホルダは、時間の経過や環境の変化によって各々の目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化に対し、ステークホルダは熟慮し、相互に合意した上で、適切な時期にシステムの変更を要求する。DEOSプロセス100はこのような要求に対するサイクルとして、上述の変化対応サイクル100−01を備える。
対象システムは、不完全さと不確実さに起因する障害を完全に回避することが困難である。障害の予兆を検出した場合には障害を未然に回避するが、不幸にも障害が発生してしまった場合には、迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。DEOSプロセス100では、そのような状況に対応するために上述の障害対応サイクル100−02を備える。
合意形成プロセス100−03は、要求抽出/リスク分析(requirements elicitation / risk analysis)フェーズ100−09と、ステークホルダ合意(stakeholders' agreement)フェーズ100−10とから構成される。この合意形成プロセス100−03は、目的変化/環境変化イベント(objectives/environment change)100−19によって、または、障害対応プロセス100−06の結果次第で起動される。
要求抽出/リスク分析フェーズ100−09では、組織の行動規範のもと、ビジネスビジョン、ユーザニーズ、ステークホルダの目標、多様なシステム環境、規制などから対象システムに係る要求が抽出される。また、それと同時に、サービス継続(service continuation)シナリオが開発される。要求抽出/リスク分析フェーズ100−09の結果は、一連のディペンダビリティ要求である。このディペンダビリティ要求は、文書形式のデータであり、その開発過程での生成物とともに、合意記述データベース110に記録され(100−20)、後続のプロセスでの利用に備える。
ステークホルダ合意フェーズ100−10は、複数のステークホルダによる対象システムにおいて、何を、何故、如何に変更するか、ということに関する議論から始まる。この議論のプロセス、および、その結果としての合意は、後述のD−Caseとして論理的に記述される。ステークホルダ合意フェーズ100−10は、サービス継続シナリオからの実行可能手続きを生成する。この実行可能手続きは障害対応に利用される。そして、上述の要求抽出/リスク分析フェーズ100−09と同様に、このステークホルダ合意フェーズ100−10において開発された生成物は、主に文書形式のデータであり、合意記述データベース110に記録され(100−20)、後続のプロセスでの利用に備えるとともに、前段の要求抽出/リスク分析フェーズ100−09での生成物との間の関連リンクが生成される。
開発プロセス100−04は、設計フェーズ100−11と、実装フェーズ100−12と、検証フェーズ100−13と、テストフェーズ100−14とから構成される。
設計フェーズ100−11では、前段の合意形成プロセス100−03の結果として合意された要求を、例えば、如何に対象システムに実装し、運用していくかが議論され、必要な仕様書にまとめられる。
実装フェーズ100−12では、設計フェーズ100−11における仕様書から必要なプログラムコードを記述し、または、必要な技術を実現するプログラムコードを調達し、必要な運用のためのシステムの構築などを行う。
検証フェーズ100−13では、実装フェーズ100−12の結果が合意形成プロセス100−03の結果と矛盾してないかが検査される。プログラムの論理的整合性、プログラミング言語矛盾などが検査される。
テストフェーズ100−14では、性能検証のためのベンチマークや耐障害テストなどにより、合意形成プロセス100−03におけるステークホルダ合意の通りに対象システムが動作するかが確認される。
これら開発プロセス100−04の各フェーズにて開発された生成物は、文書形式のデータや、プログラムコード形式のデータであり、合意記述データベース110に記録され(100−21)、前段の合意形成プロセス100−03にて開発された生成物との間の関連リンクが生成され、後段の説明責任遂行プロセス100−05を含む他のプロセスやサイクルでの利用に備える。
障害対応プロセス100−06は、通常運用状態100−07から起動され、未然回避(failure prevention)フェーズ100−15と、迅速対応(responsive action)フェーズ100−16と、原因究明(cause analysis)フェーズ100−17とから構成される。
未然回避フェーズ100−15は、予兆検知/障害発生イベント100−18における、特に予兆検知によって起動される。障害の予兆が検知されたことにより、その障害を回避するための必要な対策が実行される。上述の実行可能手続きの実行によってその対策が実行される場合もあり、また、必要な原因究明フェーズ100−17を経て合意形成プロセス100−03が起動されてステークホルダによる対策が実行される場合もある。どちらの場合も、合意記述データベース110がアクセスされる(100−24)。この実行可能手続きは合意記述データベース110から必要に応じて対象システムにデプロイされる。また、合意形成プロセス100−03が起動された場合にも、合意記述データベース110がアクセスされ(100−24)、必要な対策が同定される。
一方、迅速対応フェーズ100−16は、予兆検知/障害発生(anomaly detection / failure)イベント100−18における、特に障害発生によって起動され、その障害から対象システムを通常運用状態100−07に回復させる対策が実行される。未然回避フェーズ100−15と同様に、実行可能手続の実行によってその対策が実行される場合もあり、また、必要な原因究明フェーズ100−17を経て合意形成プロセス100−03が起動されてステークホルダによる対策が実行される場合もある。どちらの場合も、合意記述データベース110がアクセスされる(100−24)。この実行可能手続きは合意記述データベース110から必要に応じて対象システムにデプロイされる。また、合意形成プロセス100−03が起動された場合にも、合意記述データベース110がアクセスされ(100−24)、必要な対策が同定される。
通常運用状態100−07は、対象システムが通常の運用状態にあることを示している。この通常運用状態100−07は、対象システムがステークホルダ間で合意されたサービスレベル変動許容範囲(in-operation range)から大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクル100−01は、通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクル100−02も、通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、サービスレベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。または、一部の機能を縮退してサービスを継続している場合もある。しかしながら、サービスの提供が完全に停止されてしまう場合もある。
通常運用状態100−07において実行されるプロセスには、日常的な動作記録の点検、プロセスの定期的な見直しや改善、要員の訓練、しつけおよび教育など、継続的なディペンダビリティ向上活動が含まれる。システムの稼働状況を記録し、日々点検することにより、保守担当者や運用担当者が何かの兆候をそこから見出すことができる可能性がある。また、システムのメモリ資源を常にクリーンな状態にすることも、非常に有効な日常保守または改善活動である。または、積極的に予行を行うことも有効である。障害は、ある時間が経過してある状態に達した時に発生する。そうであれば、時間を先に経過させると障害の発生を事前に知ることができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかはその時の状況による。
この通常運用状態100−07においても合意記述データベース110がアクセスされる(100−23)。対象システムがサービスレベル許容範囲にある状態であるかどうかを監視するための実行可能手続きは当該データベースから対象システムにデプロイされている。また、対象システムにて取得されている各種ログについて、必要な分が抽出され、適切な形式に変換され、合意記述データベース110に送られるというETL(Extract / Transform / Load)処理によっても、対象システムの状態がサービスレベル許容範囲にあるかが判断される。
説明責任遂行プロセス100−05では、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者および社会に対し、障害状況、迅速対応および今後の見通しなど説明する。また、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか(変化するのか)を説明する。日常のサービス遂行状況や、設計開発/保守運用プロセスに関する説明が必要なときもこれに対応する。これらは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。説明責任遂行の為に必要な情報は、合意記述データベース110に記録されているため、必要に応じてアクセスされる(100−22)。
<合意記述データベース(D−ADD)の概要>
図2は、本実施の形態に係る合意記述データベース110の構成例の概略を示す機能ブロック図である。この合意記述データベース110は、請求の範囲に記載のデータベースシステムの一例である。
合意記述データベース110は、対象システム210とネットワーク220を介して結ばれている。対象システム210は、別個の2台以上のコンピュータから構成されるシステムであってもよい。2台以上のコンピュータから構成される場合には、各コンピュータはネットワーク220によって接続され得る。この実施の形態におけるネットワーク220は、専用回線であってもよく、インターネットを含む公衆回線であってもよく、公衆回線上にVPN技術を用いて仮想的な専用回線を構築したものであってもよく、また、1台のコンピュータ内部のOSの提供する通信回線であってもよい。以下では、特に断らない限りネットワークを上述のように定義する。
合意記述データベース110は、ルールエンジン部200−01、モデル処理部200−02、永続化部200−03、ハイブリッドデータベース部200−04、および、基本ツール部200−05から構成される。
モデル処理部200−02は、1以上のデータモデルを定義する。変化対応サイクル100−01、障害対応サイクル100−02、および、通常運用状態100−07において開発され、または生成された生成物は、合意記述データベース110に記録される際に、モデル処理部200−02において処理され、管理される。すなわち、このモデル処理部200−02は、対象システムのライフサイクル全般に亘って生成される複数の生成物に基づいて複数のモデルを処理する。
ルールエンジン部200−01は、対象システムのオープンシステムディペンダビリティを維持するためのルールを管理するとともに、そのために必要な処理をモデル処理部200−02において管理されているデータモデルに従って実行する。すなわち、このルールエンジン部200−01は、複数のモデルに基づいて複数の生成物の関係および制約に関する条件およびその条件に応じた処理をルールとして定義する。
永続化部200−03は、モデル処理部200−02において管理されているデータモデルに従って、上述の生成物を下位のハイブリッドデータベース200−04に記録する。
基本ツール部200−05は、他部の機能を利用して、合意記述データベース110を利用するための基本的ツールを提供する。各部の機能の詳細は後述する。
<ハードウェア構成>
図3は、本実施の形態に係る合意記述データベース110および対象システム210のハードウェア構成例を示す図である。最も基本的な構成としては、合意記述データベース110および対象システム210は、命令バスおよびデータバスによって接続された演算装置300−01と、制御装置300−02と、メモリ装置300−03と、入出力装置300−04とを備えた電子計算機である。
入出力装置300−04から入力されたビットデータの情報に基づいて、演算装置300−01において、算術演算、論理演算、比較演算、シフト演算などが実行される。実行されたデータは、必要に応じて、メモリ装置300−03に記憶され、入出力装置300−04から出力される。これら一連の処理は、メモリ装置300−03に記憶されたソフトウェアプログラムに従って、制御装置300−02によって制御される。本実施の形態における合意記述データベース110および対象システム210は、上述のコンピュータとしての基本機能を備えたハードウェアであり、オペレーティングシステムやデバイスドライバ、ミドルウェア、アプリケーションソフトウェアといった複数のプログラムによって制御される。
<合意記述データベース(D−ADD)の機能構成>
図4は、本実施の形態における合意記述データベース110の機能構成例を示す図である。
ここでは、DEOSプロセス100における通常運用状態100−07、変化対応サイクル100−01、障害対応サイクル100−02、および、説明責任遂行プロセス100−05から説明する。まず、通常運用状態100−07は、対象システム210を通常運用状態に維持する活動である。対象システム210は、ステークホルダによって合意され、責任者によって承認されたD−Caseと附随する実行可能手続きにより様々の記録が取られている。それらの活動や記録からは、生成物3250−13が生み出される。
ビジネス環境の変化等の理由で対象システムが通常運用状態100−07を維持できなくなった時には、変化対応サイクル100−01が始まる。ここでは、合意記述データベース110の構成要素であって基本ツール部200−05に含まれる合意形成支援ツール250−01を利用して、ステークホルダ間でその変化への対応策が議論され、ソリューションが合意され、生成物1250−11となる。この際に、生成物3250−13のどの項目がその変化に対して脆弱であったか検査され、生成物1250−11内のソリューションと関連付けられる。
ソリューションに基づいて対象システム210が更新されると、説明責任遂行プロセス100−05が開始される。ここでは、どのような事由により、どのようなソリューションが開発され、対象システムが更新されたかの情報が、基本ツール部200−05の構成要素である説明責任遂行支援ツール250−02を用いて、生成物2250−12としてまとめられる。
これらの生成物は、モデル処理部200−02において複数のモデルに分解され、永続化部200−03に上述のように記録され、変化または変更や関連性がルールエンジン部200−01において上述のように処理される。このようにして、この例における生成物3250−13に記載の脆弱性が、生成物1250−11に記載のソリューションと関連しており、そのソリューションが、生成物2250−12に記載の対象システム210の更新内容に関連付けられる。
<合意記述データベース(D−ADD)の構成>
図5は、本実施の形態における合意記述データベース110の内部構成例を示す図である。この合意記述データベース110の中核を構成するのが中核部(Core)400−01である。この中核部400−01は、ルールエンジン部200−01、モデル処理部200−02、永続化部(Persistence)200−03、および、AC API部400−10から構成される。
ルールエンジン部200−01は、ルール処理部(Rule Processing)400−05と、スクリプト処理部(Script Processing)400−06とを含む。ルール処理部400−05は、複数のルール記述(a Rule)400−07を処理する。スクリプト処理部400−06は、複数のスクリプト記述(a Script)400−08を処理する。
モデル処理部200−02は、複数のモデル記述(a Model)400−09を処理する。複数のモデル記述400−09の各々は、ルールエンジン部200−01において計算されるデータのモデルを定義するとともに、永続化部200−03に記録するデータのモデルを定義する。
AC API部400−10は、ルールエンジン部200−01における処理に必要な権限モデルを管理する。
永続化部200−03は、下位のハイブリッドデータベース200−04に対するアクセスを抽象化するものである。
ハイブリッドデータベース200−04は、索引部(Indexing)400−13、グラフデータベース(Graph DB)400−14、XMLデータベース(XML BD)400−15、および、文書データベース(Document DB)400−16から構成される。索引部400−13は、下位のデータベース(400−14、400−15および400−16)に対して索引処理を実行する。
なお、上述の構成例は、DEOS実行環境(D−RE)400−21上で稼働するように構成されるが、他の構成手段を採ってもよい。
図6は、本実施の形態における合意記述データベース110のArchiMate(登録商標)形式による表現例を示す図である。同図は、全てArchiMate(登録商標)仕様に定められるアプリケーション層の記述のみを描いている。なお、ArchiMate(登録商標)の仕様については、以下のURLから参照可能である(http://www.opengroup.org/subjectareas/enterprise/archimate)。
基本ツール群を含むアプリケーション(Application)410−01は、D−ADD API410−03を経由して、D−ADD(合意記述データベース110)にアクセスする。コンソールAPI(Console API)410−04は、D−ADD API410−03を拡張し、SDK等(SDK etc.)410−02の合意記述データベース110を構成するためのツール群からアクセスするためのAPIを定義する。
D−ADD API410−03は、図5のルール処理部400−05、スクリプト処理部400−06およびモデル処理部200−02に各々対応する、Rule Processingコンポーネント410−05、Script Processingコンポーネント410−06およびModel Processingコンポーネント410−07によって実現される。
Rule Processingコンポーネント410−05は、複数のデータオブジェクト(図中では「a Rule」)410−08にアクセスする(410−16)。Rule Processingコンポーネント410−05は、データオブジェクト410−08に記載されたルールを解釈し、条件が真のルールに記載されたアクションを実行し、そのデータオブジェクトに関連したデータオブジェクト(図中では「a Script」)410−21をScript Processingコンポーネント410−06で実行する。
Script Processingコンポーネント410−06は、複数のデータオブジェクト(図中では「a Script」)410−21や410−22に記載の処理を実行する(410−20等)。
Model Processingコンポーネント410−07は、複数のデータオブジェクト(図中では「a Model」)410−09にアクセスする(410−17)。これらデータオブジェクト410−09はデータ型であり、複数のインスタンス410−10のデータ型を決定する(410−18)。これらインスタンス410−10は、Rule Processingコンポーネント410−05、Script Processingコンポーネント410−06およびModel Processingコンポーネント410−07からアクセスされる(410−19)。
Persistenceインターフェース410−11は、永続化部200−03に対応する。このPersistenceインターフェース410−11は、Indexingサービス410−12、Graph DBサービス410−13、XML DBサービス410−14およびDocument DBサービス410−15から構成されるハイブリッドデータベースを利用して、抽象化されたインターフェースを定義している。なお、上述の構成以外の構成方法によって合意記述データベース110を構成してもよい。
図7は、本実施の形態における合意記述データベース110内部に記録されるデータ間の関係の概略を示す図である。データは、ベース層500−01またはメタ層510−01に属する。本実施の形態において、ベース層500−01は、データが独立して存在している論理空間である。一方、メタ層510−01は、ベース層500−01のデータの関係・制約に関するデータが存在している論理空間である。なお、ベース層500−01のデータには他のデータへの参照を含んでいるデータもあり、全ての関係・制約に関するデータがメタ層510−01に存在しているとは限らない。本実施の形態では、特にディペンダビリティ要件に関するデータをメタ層510−01に配置するが、実施に当たっては他の形態をとってもよい。
ベース層500−01には、上述のDEOSプロセス100の実行によって、各種の文書データ(要求500−02、仕様500−03、設計500−04、運用500−06、等)、プログラムデータであるコード500−06、開発中結果500−07、テスト結果500−08、運用ログデータ500−09等が生成される。それらは、D−Case(500−10、500−11、500−12)の付帯文書として永続化部200−03に記録される。また、これら複数の付帯文書は後述する関連リンクによって繋がっている。
一方で、どのデータがどのように繋がっているか、繋がりの有効期限、データの特性、データの制約、等々の組織固有の行動規範510−02(ビジネスビジョンや組織内規)や規制510−03に影響を受けるデータを、ここでは関係・制約記述データ(510−04、510−05、510−06)とよび、これら関係・制約データをメタ層510−01に配置する。同図において、関係・制約記述データ510−04は、要求500−02と、仕様500−03と、D−Case500−10と、コード500−06との関係および制約に関する。関係・制約記述データ510−05は、D−Case500−12と、運用500−05と、運用ログ500−09との関係および制約に関する。関係・制約記述データ510−06は、D−Case500−11と、開発中結果500−07と、テスト結果500−08との関係および制約に関する。
<ベース層における関連性>
図8は、本実施の形態のベース層500−01における各種データの関連性を示す図である。この図は本実施の形態における一例であり、これに限定されるものではない。この図では、ディペンダビリティに関するステークホルダからの要求を記述したD−Case600−01を中心として、その要求の詳細記述600−04と、要求詳細記述600−04に基づく仕様600−05と、テスト結果600−03とが関連しているものとして図示している。
プログラムコード600−06は、仕様600−05に基づいて開発された成果物であるため、関連がある。プログラムコード600−06は、テスト結果600−03と関連がある。D−Case600−02は、運用に関するステークホルダ要求を記載している。このD−Case600−02は、運用手順書600−07および運用ログ600−08と関連がある。運用ログ600−08は、運用手順書600−07に基づいてログを記録する。運用手順書600−07は、コード600−06に基づいて運用する。これら文書は全てステークホルダによって合意された状態(610−01)の文書である。これらは、DEOSプロセス100を構成する通常運用状態100−07からアクセスされるのみならず、変化対応サイクル100−01および障害対応サイクル100−02からもアクセスされる。
図9は、本実施の形態のモデル処理部200−02における表現例を示す図である。ここでは、図8に示した状態を想定している。図8のD−Case600−01に対応するモデルは、UML形式のモデルによって合意記述データベース110に記録される際には、点線円620−01で示した複数のノードとして表現される。ここでは、ゴール620−06、コンテキスト620−07、ストラテジ620−08、ゴール620−09、ゴール620−10、エビデンス610−11および620−12が、D−Case表現の木構造を維持した状態で合意記述データベース110に記録される。
要求600−04は、一般に複数存在するため、ここでは点線円620−02で示した3ノードとして表現される。この要求600−04は、要求1620−13、要求2620−14および要求3620−15から構成される。この要求600−04は、仕様600−05に繋がっており、要求600−04に基づいて仕様600−05が開発された旨を示している。
仕様600−05は、仕様1620−16および仕様2620−17から構成され、仕様1620−16は要求1620−13と、仕様2620−17は要求3620−15とそれぞれ関係している。図8において仕様600−05に基づいてコード600−06が開発され、コード600−06を用いてテスト結果600−03が作成されているため、図9では仕様1620−16と仕様2620−17とともにコード620−18が関係するように合意記述データベース110に記録される。コード620−18は、テスト結果620−19と関係している。
また、図8におけるD−Case600−02は、図9では点線円620−04を構成するゴール620−20とエビデンス620−21として表現される。図8ではD−Case600−02に基づいて運用600−07文書が開発され、それに基づいて運用ログが記録される。図9ではゴール620−20は運用1620−22と関係し、運用2620−23は運用ログ620−24と関係するように合意記述データベース110に記録される。そして、運用ログ620−24は、エビデンス620−21に関連付けられて合意記述データベース110に記録される。
図10は、本実施の形態におけるD−Caseを記録するモデルの一例をUML形式で示す図である。D−Case表現の構成要素は、Goalクラス630−05、Strategyクラス630−06、Contextクラス630−07、Undevelopedクラス630−08、Evidenceクラス630−09、および、Evidenceクラス630−09をサブクラスに持つMonitorクラス630−10である。これらのクラスは、全てNodeクラス630−03のサブクラスであり、NodeSetクラス630−02に集約される。NodeSetクラスは、DCaseクラス630−01に集約されるとともに、Nodeクラス630−03を集約している。D−Caseの付帯文書は、DCaseDocumentクラス630−04下に特殊化される。この図では付帯文書のクラス図は示していない。
<メタ層における関連性>
図11は、本実施の形態のメタ層510−01における各種データの関連性を示す図である。ここでは、ある対象システムAが2個のソフトウェア部品を利用している状況を想定している。対象システムAのD−Case700−02、その部品BのD−Case700−03と部品CのD−Case700−04が存在している。それぞれ対象システムAの部品であるため、部品Bと部品CのD−Case(700−03および700−04)は、対象システムAのD−Case700−02とは独立していて、それらの間に何らディペンダビリティ要求を記述した文書(D−Caseはその一例)が存在しないことになる。本実施の形態では、このような関係・制約を記述するデータを導入し、特にディペンダビリティ要求をD−Case形式で記述したデータを「メタD−Case」と呼ぶ。この図では、メタD−Case700−01がそれに該当し、対象システムAとその部品BおよびCのD−Case間の関係を記述する。
図12は、本実施の形態のメタ層510−01における各種データの関連性を示す他の図である。ここでは、対象システムAが部品供給者から2個のソフトウェア部品の提供を受けて対象システムを構築している状況を想定している。対象システムAのD−Case710−02には、提供を受ける2個の部品のD−Case(710−03および710−04)への依存関係が存在し、ここでは、対象システムAのD−Case710−02のあるディペンダビリティ要求を満たすエビデンスに関連付けている。この例の場合には、2個の部品各々に対するディペンダビリティ要求は対象システムAのD−Caseに記述されている。しかし、3者(710−02、710−03および710−04)のD−Case間の関係、例えば、部品間の処理順序の制約からくるディペンダビリティ要求、または、部品間での相互依存の制約からくるディペンダビリティ要求、等の3以上のD−Case間の関係はメタD−Case710−01に記述する。
図13は、本実施の形態のメタ層510−01におけるメタD−Caseの記述例を示す図である。トップゴールG_1は、「app_1はserv_1に依存している」(720−01)である。ここで、app_1は単純なチャットアプリケーションであり、serv_1はそのアプリケーションを実行するために既存のクラウドサービスにデプロイされた実行環境である。クラウドサービス業者との間にはSLA(Service Level Agreement)が締結されている。この状況はコンテキストC_1に記載され(720−02)、そこにはベース層500−01に存在するapp_1のD−Case、serv_1のD−Case、および、SLAへのリンクが記載されている。
これらの情報は、合意記述データベース110内部ではモデル処理部200−02において対応するモデル定義に従って、データとその関連性が記録されている。トップゴールG_1は、ストラテジS_1ノードにおいて「SLAに従って議論を分解」(720−03)している。
サブゴールは3つ存在する。サブゴールG_1.1は「どのようなエラーが返されるか同定されている」(720−04)ことであり、サブゴールG_1.2は「反応時間は10ms以内である」(720−05)ことであり、サブゴールG_1.3は「SLAが有効期限内である」(720−06)ことである。各々にエビデンスが存在している。エビデンスE_1は「エラーが返された時の処理が同定されている」(720−07)であり、テスト結果の文書が付帯することによってサブゴールG_1.1を満たす。
エビデンスM_1はD−Caseモニタリングノードであり、「反応時間を計測するスクリプトが導入され稼働されている」(720−08)とあり、対応するスクリプトが導入され実行され、その結果を判断することによって、サブゴールG_1.2が満たされているかが判明する。エビデンスM_2も同様に、D−Caseモニタリングノードであり、「SLAの有効期限を確認するスクリプトが導入され稼働している」とあり、対応するスクリプトが導入され実行され、その結果を判断することによって、サブゴールG_1.3が満たされているかが判明する。
<モデル処理部とルールエンジン部>
図14は、本実施の形態におけるモデル処理部200−02およびルールエンジン部200−01の機能構成例を示す図である。モデル処理部200−02は、モデル定義部230−01、モデルインスタンス導入部230−02、モデル変更部230−03、モデル記録部230−04、および、メタモデル処理部230−05の5つの機能ブロックから構成される。ルールエンジン部200−01は、条件評価準備部230−10、条件評価部230−11、ルール順序化部230−12、スクリプト抽出部230−13、および、スクリプト実行部230−14の5つの機能ブロックから構成される。ルールエンジン部200−01において、条件評価準備部230−10、条件評価部230−11、および、ルール順序化部230−12は、上述のルール処理部400−05に対応する。そして、スクリプト抽出部230−13、および、スクリプト実行部230−14は、上述のスクリプト処理部400−06に対応する。
モデル定義部230−01は、新しいモデルを定義する際に利用される。例えば、図10に示したD−Caseモデルを合意記述データベース110に定義するのは、モデル定義部230−01の機能である。このモデル定義部230−01は、新しいモデルを定義すると、ルールエンジン部200−01を構成する条件評価準備部230−10に対して、ルール条件の準備を指示する。例えば、図10に示したD−Caseモデルの場合には、新しいD−Case記述の合意記述データベース110への登録を契機としたD−Caseモデルインスタンスを生成するルール、D−Caseが変更された時のルール、D−Caseエビデンスノードの充足を確認するルール、D−Caseモニタリングノードに附随した実行可能手続きの署名を検証するルール、等々のD−Caseの妥当性を検証するための複数のルールが、ルールエンジン部200−01のルール処理部400−05に導入される。
モデルインスタンス導入部230−02は、合意記述データベース110に新しい文書データが記録される際に、その文書データのモデルを決定し、モデル処理部200−02にモデルインスタンスとしてその文書データを読み込み、モデル記録部230−04を利用して、そのモデルインスタンスを永続化部200−03から記録する。その後、条件評価部230−11に対してルール条件の評価を依頼する。
条件評価部230−11は、該当するルールを抽出し、ルール順序化部230−12において2以上の該当ルールが抽出された際の実行順序を決定する。並列処理が構成されている場合には、ルールは並列に実行される。順序が決定されたルールについて、スクリプト抽出部230−13によってスクリプトが抽出される。そして、その抽出されたスクリプトがスクリプト実行部230−14によって実行される。
モデル変更部230−03は、モデル記録部230−04に存在するモデルを変更または更新する機能を有する。例えば、図10に示したD−Caseモデルのインスタンスを変更する際には、柳澤らの文献(Yukiko Yanagisawa, Takashi Ito, Makoto Takeyama and Yasuhiko Yokote: "A New Method of Consensus Building for Open Systems Dependability", 3rd Workshop on Open Systems Dependability, WOSD2013, ISSRE2013)に記載の手法を用いてもよい。この手法を用いると、合意形成プロセス100−03の進行に従ってD−Caseのノードがモデル変更部230−03によって追加され、モデル記録部230−04によって記録される。
モデル記録部230−04は、永続化部200−03を通してアクセスされるハイブリッドデータベース200−04からはキャッシュに見える。すなわち、主メモリ上のモデルやモデルインスタンス、ルールはより広大なメモリ空間を有するハイブリッドデータベース200−04の情報空間の一部が写像され、モデル記録部230−04は写像を管理している。
メタモデル処理部230−05は、メタD−Caseを処理する機能ブロックである。図10に示したD−CaseモデルにおけるNodeクラス630−03に定義されたメタ属性630−20が"null"で無い場合、すなわち、あるD−Caseに対してメタD−Caseが存在する場合、メタD−Caseを評価し、ベース層のD−Caseと互換性があるか検証される。例えば、図13に示したメタD−Caseの場合には、そのD−Caseがapp_1に関するD−Caseであり、app_1はserv_1に関するD−Caseを必要としている。メタモデル処理部230−05は、必要な全てのD−Caseの存在を確認し、メタD−Caseに記載されているエビデンスノードの妥当性を確認する。全ての妥当性が確認されれば、メタD−Caseに対応するベース層のD−Caseは互換であるとみなされ、必要なディペンダビリティ要求を満たしていると判断することができる。
図15は、本実施の形態のルール処理部400−05におけるルール処理の例を示す図である。ここでは、ルール処理部400−05で処理されるルールに関するUMLクラス図の例を示している。ルール(図中では「Rule」)800−01は、条件部(図中では「RuleCondition」)800−02、アクション部(図中では「RuleAction」)800−03、結果記録部(図中では「RuleExperience」)800−04、および、ルール文脈部(図中では「RuleConext」)800−05から構成される。本実施の形態では、複数のルールを1グループとして取り扱うことができるようにルール集合を導入した。これにより、グループ内のルールの評価順序を指定し、アトミック処理を構成し、権限管理の単位とすることが可能となる。ここでは、ルール集合をRuleSetクラス800−08として示す。ルールは1以上のルール集合に含まれる。ルール集合には付帯ドキュメント(図中では「RuleSetDocument」)800−09が関連付けられる。
図16は、本実施の形態のルール処理部400−05におけるルール記述の例を示す図である。ここでは、1個のルールセット810−01が定義されている。名称は「SystemLoadConditioner」であり、D−Caseモニタリングノードに対応するルールとして例示する。ルールセット810−01には2個のルール810−02および810−05が定義されている。ルール810−02は、メモリ残量が既定値(in-operation range)よりも少なくなったときに真となる。ルール810−05は、CPU使用率が規定値よりも少なくなったときに真となる。この条件が810−03および810−06に示され、条件が真となった場合のアクションが810−04および810−07に示される。
<データの永続化>
図17は、本実施の形態におけるデータの永続化の例を示す図である。ここでは3つのモデルが示されている。D−Caseノードのモデル900−01、付帯情報のモデル900−02およびログ等のデータのモデル900−03である。これらのモデルは、永続化部200−03を経由して下位のハイブリッドデータベース200−04に記録される。記録に際して、まず、Indexing400−13によって索引が記録される(900−09)。同時に、各モデルはモデルのクラスによって記録されるデータベースが決定される。例えば、モデル900−01のインスタンスは、Graph DB400−14にグラフ構造900−11として記録される。付帯情報900−02のモデルは、そのインスタンスがXML DB400−15にタグ付きデータ900−12として記録される。ログ等のモデル900−03は、そのインスタンスがDocument DB400−16に非構造データ900−13として記録される(900−10)。
また、上述の条件部とプロシジャ部から構成されたルール900−04が1つ描かれている。ルール内の条件部(図中では「cond.」)はモデルを参照できる。ここでは、ルール900−04の条件部は、モデル900−01を参照している。条件部が真である場合には、プロシジャ部(図中では「proc.」)に関連付けられたスクリプトが実行される。この図では、ルール900−04の条件部が真である場合には、スクリプト900−05が実行される。その結果、データを更新してもよい。この図では、データ900−13を更新している(900−07)。更新されたデータはモデルに反映される。この図ではデータ900−13の更新の反映(900−08)により、モデル900−03が変化する。これらの処理は並列処理を行うことによって高速化することが可能である。
<合意記述データベースの動作>
図18は、本実施の形態に係る合意記述データベース110の要部の機能構成例を示す図である。また、図19は、本実施の形態に係る合意記述データベース110における処理手順例を示す図である。以下の処理は、DEOSプロセス100を実行する過程で生成された全ての生成物に対して実行される。
DEOSプロセス100を実行する過程で生成物が生成されると、その生成物はモデル処理部200−02に入力される(パス811)(ステップS911)。すなわち、DEOSプロセス100の実行の過程で利用される、合意形成支援ツール250−01、説明責任遂行ツール250−02等の基本ツール部200−05からの出力が、生成物として合意記述データベース110にモデルインスタンス導入部230−02を利用して入力される。
次に、モデル処理部200−02によって、生成物に対応するモデルが永続化部200−03に存在するか否かが調べられる(ステップS912)。存在しない場合には(ステップS912:No)、モデル定義部230−01が、新しいモデルを定義して(ステップS913)、そのモデルに対応するルールをルールエンジン部200−01の条件評価準備部230−10に入力する(パス821)(ステップS914)。ここで、ルールは、複数の生成物の関係および制約に関する条件およびその条件に応じた処理を表す。条件評価準備部230−10は、モデルに附随するルールおよびそのルールに対応するスクリプトを定義して、モデル記録部230−04に供給する(パス822)。モデル記録部230−04は、永続化部200−03のインターフェースを利用して(パス823)、条件評価準備部230−10から供給されたルールおよびスクリプトを、文書データベース400−16に記録する(パス851)。
モデルインスタンス導入部230−02は、永続化部200−03のインターフェースを利用して(パス812)、文書データベース400−16に生成物を記録する(パス851)(ステップS915)。また、モデルインスタンス導入部230−02は、生成物から対応するモデルに従った構造を構造データとして抽出して、永続化部200−03のインターフェースを利用して(パス813)、抽出された構造データをXMLデータベース400−15に記録する(パス852)(ステップS915)。さらに、モデルインスタンス導入部230−02は、生成物に対応するモデルと他のモデルとの関係を示す関係データを抽出して、永続化部200−03のインターフェースを利用して(パス814)、抽出された関係データをグラフデータベース400−14に記録する(パス853)(ステップS915)。なお、これらの処理において、永続化部200−03が各種データベースにアクセスする際には、同時に索引部400−13にインデクスが記録される(パス854)。
条件評価部230−11は、生成物から抽出されたモデルに附随したルールを評価して、発火条件を検査することにより、発火すべき(処理対象となる)ルールを抽出して、ルール順序化部230−12に供給する(パス832)(ステップS916)。その際、永続化部200−03のインターフェースを利用して(パス831)、そのモデルに関連するモデルがグラフデータベース400−14において検索され(パス853)、関連するモデルに附随するルールが文書データベース400−16から取り出される(パス851)。
ルール順序化部230−12は、供給された複数のルールの発火順序を決定して、スクリプト抽出部230−13は、それぞれのルールに対応するスクリプトを抽出する(パス833)。すなわち、これによってスクリプトの実行順序が決定される(ステップS917)。このようにして決定された実行順序に従って、それらスクリプトをスクリプト実行部230−14が実行する(パス834)(ステップS918)。
モデルにメタモデルが附随しているときには(ステップS919:Yes)、メタモデル処理部230−05は、そのメタモデルの関係および制約の条件を検証して、充足処理を実行する(ステップS921)。メタモデル処理部230−05は、その過程で、必要なデータを永続化部200−03のインターフェースを利用して(パス841)、モデルは文書データベース400−16から(パス851)、構造データはXMLデータベース400−15から(パス852)、関係データはグラフデータベース400−14から(パス853)、それぞれ取得する。また、その過程で、モデルの変更が必要な場合には(ステップS922:Yes)、モデル変更部230−03がモデルの変更を行う(ステップS923)。変更されたモデルは、モデル記録部230−04に供給され(パス842)、永続化部200−03のインターフェースを利用して(パス823)、文書データベース400−16、XMLデータベース400−15、または、グラフデータベース400−14の何れかに記録される(パス851乃至853)。
このように、本発明の実施の形態によれば、システム規模の拡大や複雑度の増大により複雑になるステークホルダ要求やD−Caseを含む生成物を分断し、それらの間の関係および制約を関係・制約データとして定義することにより、対象システムに関するディペンダビリティ要求をステークホルダが漏れなく、誤解もなく理解し、合意することができ、対象システムのディペンダビリティを、そのシステムのライフサイクル全般に亘って維持するために統御することができる。
また、本発明の実施の形態によれば、新しいシステムを既存のシステムに接続する際に、新しいシステムに関するD−Caseが対応する関係・制約データに記載の内容に合致すれば、ディペンダビリティへの影響を制御することができる。
また、本発明の実施の形態では、目的や環境の変化の際に、対象システムに関する前後の関係の把握が可能となるため、変化の前後で構造が変わりうる場合であっても、その対象システムを取り扱うことができる。
また、本発明の実施の形態におけるリポジトリ構成によれば、オープンシステムディペンダビリティを維持するために要求されるデータを、情報の構造に制約されることなく、ディペンダビリティ特性(dependability attributes)を犠牲にすることなく、永続化(persistence)することができる。
なお、上述の実施の形態は本発明を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本発明の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本発明は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。
また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、CD(Compact Disc)、MD(MiniDisc)、DVD(Digital Versatile Disc)、メモリカード、ブルーレイディスク(Blu-ray(登録商標)Disc)等を用いることができる。