JP2015111411A - データベースシステムおよびその制御方法 - Google Patents

Abstract

【課題】対象システムがオープンシステムディペンダビリティを維持するとともに、ステークホルダが説明責任を達成するためのデータベースを提供する。【解決手段】モデル処理部は、目的または環境の変化に対してシステムを継続的に変更していくためのサイクルと障害に対して迅速に対応するためのサイクルとを備える反復的プロセスに準拠して開発または運用の少なくとも何れかが行われる対象システムのライフサイクル全般に亘って生成される複数の生成物に基づいて複数のモデルを処理する。ルールエンジン部は、複数のモデルに基づいて複数の生成物の関係および制約に関する条件およびその条件に応じた処理をルールとして定義する。永続化部は、複数の生成物を記複数のモデルおよびルールとともに記録する。【選択図】図１８

Description

本発明は、データベースシステムに関する。詳しくは、対象システムのディペンダビリティを担保するためのデータベースシステムおよびその制御方法に関する。

情報システムには、そのシステムの提供するサービスを安心して継続的に利用できることが要求される。その一方で、情報システムの障害事例はむしろ増加の傾向にあるといえる。例えば、クラウドサービスの障害により何千という顧客企業のデータが消失する事故が起きている。通信システムの障害は企業活動のみならず我々の生活にも多大の影響を与える。そして、その様な障害は通信サービスを提供している企業の存続をも脅かしている。医療現場では研究に資することで医療技術の向上に繋がるデータがあっても、利用環境のディペンダビリティに関する懸念から２次利用ができない。これらの障害は巨額の賠償金に発展するケースもある。もし、大きな事故が起これば責任の追及が行われ、過誤が認定されれば厳しい罰則を受けることをステークホルダは覚悟しなければいけない。

これらは、もっぱらシステム規模やそれを取り巻く環境の拡大や複雑度の増大に起因している。従来からシステムの信頼性、可用性、保守性、安全性、完全性および機密性に関しては、システムの備えるべき性質としてディペンダビリティが議論されてきている。現在の情報システムはそれらの性質を十分に満たしている。また、ＣＭＭＩやＩＳＯ ２６２６２を始めとする規格では、人為的エラーを減らす試みもなされている。それでも事故件数が減らないのは、オープン環境におけるシステムという特性への考慮が欠けているからであると考えられる。

そこで、情報システムのディペンダビリティを維持する技術体系をまとめ、制度化さらには事業化を目指すべく、２００６年に独立行政法人科学技術振興機構（ＪＳＴ）は、ＣＲＥＳＴプログラムの１つとしてＤＥＯＳプロジェクトをキックオフした。その様な技術体系を一言で言えば、システムの安全基準を定義して、それを逸脱するようなことがあれば、異常事態に陥る前に回避するか、異常事態に陥ってもすぐさま復旧させることができる技術体系であり、オープンシステムディペンダビリティ（Open Systems Dependability）として定義されている（非特許文献１）。

このオープンシステムディペンダビリティは、プロセスの観点から整理され、ＤＥＯＳプロセスとしてまとめられた（例えば、非特許文献１および特許文献１参照）。ＤＥＯＳプロセスの特徴を一言で表現するなら、ビジネスビジョンに基づき企画や設計という上流から運用までの対象システムに関するライフサイクル全体に係るオープンシステムディペンダビリティを維持するために、対象システムに係る人と物の行動を律するプロセスであり、対象システムに関わる人々（ステークホルダ）からの対象システムに対する要求に関する合意を始めとしたあらゆる議論に関する合意をベースに、対象システムを当該合意に基づく運用状態に維持する。各プロセス間での共通言語としてＤ−Ｃａｓｅが設計されている（例えば、非特許文献２参照）。

特許第５２８０５８７号

Mario Tokoro: "Open Systems Dependability - Dependability Engineering for Ever-Changing Systems", ISBN: 978-1-4665-7751-0, CRC Press (2012) 松野裕、山本修一郎: "実践Ｄ−Ｃａｓｅ〜ディペンダビリティケースを活用しよう！〜", ISBN: 978-4-86293-091-0, 株式会社アセットマネジメント (2013) Eric Redmond and Jim R. Wilson: "Seven Databases in Seven Weeks: A Guide to Modern Database and the NoSQL Movement", ISBN: 978-1934356920（英文オリジナル），ISBN: 978-4274069086（日本語訳），The Pragmatic Programmers, LLC (2012/2013)

情報システムの規模の拡大や複雑度の増大は、情報システムに係るステークホルダからの要求に漏れや誤解を生じる原因となり、その要求に基づいて開発される仕様を複雑にするとともに、その情報システム開発前に全ての仕様を完全に記述することを不可能にしている。この様な仕様の不完全性は、対応する実装の不完全性をもたらし、その情報システムが提供するサービスの振る舞いも完全には把握することができず、何をどこまで保証したらよいのか、また、それを保証可能であるのかも分からなくなる。その結果、システム障害発生の発見や掌握が遅れ、障害原因の特定が遅れ、障害からの回復が遅れるという事態をもたらしてしまう。

さらに、情報システムを取り巻く環境の変化に対応するための要求が新たに発生する。開発時点の要求にも修正が必要になる。環境の変化は事前には分かり得ないため、情報システムの現在の動作がその環境変化に確実に対応できるかは分からない。このような変化に対する不確実性は情報システムの動作予測を困難にし、その変化に情報システムが対応する際にシステム障害が最も発生しやすい。

非特許文献１や特許文献１においては、ビジネスビジョン、目的、または、環境の変化に対応するプロセス（変化対応サイクル）と、障害予兆が検知された際、または、障害が発生した際に起動されるプロセス（障害対応サイクル）とを備えたシステムが提案されている。また、非特許文献２では、その際の変化対応サイクルと障害対応サイクルとの間の共通の表現形式としてＤ−Ｃａｓｅを導入し、そのシステムに係るディペンダビリティ要求をＤ−Ｃａｓｅとして記述し、ステークホルダ間で合意することで、ステークホルダの説明責任の達成を可能にしている。

しかし、システム規模の拡大や複雑度の増大は、当該Ｄ−Ｃａｓｅをも複雑化し、誤りや誤解の混入を許すことになり、変化対応サイクルや障害対応サイクルを備えていたとしても、誤った情報に基づく対応であるため、結果としてディペンダビリティは低下してしまう。

さらに、システム規模の拡大や複雑度の増大は、情報システムにおけるアプリケーションの構成にも影響を与える。例えば、ＷＥＢシステムにおいて各種のフレームワークを利用してアプリケーションを開発したとしても、障害発生時に問題原因を切り出すことが困難であることが多い。そのため、アプリケーションを複数のサブアプリケーションによって構成することで、問題原因を特定し易く工夫することになる。その結果、データ構造が分断されることになり、複数のデータベースに分断されたデータを記録することは、相互の一貫性の問題を複雑にするとともに、ディペンダビリティを低下させることになる。例えば、非特許文献３ではデータの特性毎に最適なデータベースを用いることでデータ構造の分断に対処可能であるが、用いられる可能性のある複数のデータベース間での一貫性の問題が残るため、依然としてディペンダビリティを担保する点で課題を残している。

本発明はこのような状況に鑑みて生み出されたものであり、対象システムのオープンシステムディペンダビリティを維持する目的で対象システムのライフサイクル中に開発された様々なデータ（要求、仕様、設計、運用手順等を含む文書、プログラムコード、企画、開発、テスト、運用過程での生成物等を含む）間の関係を定義し、管理する手段を提供することにより、対象システムがオープンシステムディペンダビリティを維持することを保証し、ステークホルダが説明責任を達成することを目的とする。

本発明は、上述の問題点を解消するためになされたものであり、その第１の側面は、目的または環境の変化に対してシステムを継続的に変更していくためのサイクルと、障害に対して迅速に対応するためのサイクルとを備える反復的プロセスに準拠して開発または運用の少なくとも何れかが行われる対象システムのライフサイクル全般に亘って生成される複数の生成物から複数のモデルを生成するモデル処理部と、上記複数のモデルに基づいて上記複数の生成物の関係および制約をルールとして定義するルールエンジン部と、上記複数の生成物を上記複数のモデルおよび上記ルールとともに記録する永続化部とを具備するデータベースシステムおよびその制御方法である。これにより、対象システムの運用を通じて生成された複数の生成物の関係および制約を定義して記録することにより、オープンシステムディペンダビリティを維持するという作用をもたらす。

また、この第１の側面において、上記複数のモデルの特性に適した複数の記録処理部と、上記複数の記録処理部に対して索引処理を行う索引部とをさらに具備してもよい。これにより、モデルの特性に適した記録を行うという作用をもたらす。

本発明によれば、対象システムがオープンシステムディペンダビリティを維持することができ、ステークホルダが説明責任を達成することができるという優れた効果を奏し得る。

本発明の実施の形態において想定するＤＥＯＳプロセス１００の概要を示す図である。 本実施の形態に係る合意記述データベース１１０の構成例の概略を示す機能ブロック図である。 本実施の形態に係る合意記述データベース１１０および対象システム２１０のハードウェア構成例を示す図である。 本実施の形態における合意記述データベース１１０の機能構成例を示す図である。 本実施の形態における合意記述データベース１１０の内部構成例を示す図である。 本実施の形態における合意記述データベース１１０のＡｒｃｈｉＭａｔｅ（登録商標）形式による表現例を示す図である。 本実施の形態における合意記述データベース１１０内部に記録されるデータ間の関係の概略を示す図である。 本実施の形態のベース層５００−０１における各種データの関連性を示す図である。 本実施の形態のモデル処理部２００−０２における表現例を示す図である。 本実施の形態におけるＤ−Ｃａｓｅを記録するモデルの一例をＵＭＬ形式で示す図である。 本実施の形態のメタ層５１０−０１における各種データの関連性を示す図である。 本実施の形態のメタ層５１０−０１における各種データの関連性を示す他の図である。 本実施の形態のメタ層５１０−０１におけるメタＤ−Ｃａｓｅの記述例を示す図である。 本実施の形態におけるモデル処理部２００−０２およびルールエンジン部２００−０１の機能構成例を示す図である。 本実施の形態のルール処理部４００−０５におけるルール処理の例を示す図である。 本実施の形態のルール処理部４００−０５におけるルール記述の例を示す図である。 本実施の形態におけるデータの永続化の例を示す図である。 本実施の形態に係る合意記述データベース１１０の要部の機能構成例を示す図である。 本実施の形態に係る合意記述データベース１１０における処理手順例を示す図である。

以下、本発明を実施するための形態について説明する。

＜ＤＥＯＳプロセス＞
図１は、本発明の実施の形態において想定するＤＥＯＳプロセス１００の概要を示す図である。オープンシステムディペンダビリティ、すなわち、機能、構造、システム境界が時間とともに変化し続けるシステムに対するディペンダビリティを実現するためには、反復的プロセス（iterative process）としてのアプローチが必須である。この反復的プロセスは、目的（objectives）や環境の変化（environmental change）に対してシステムを継続的に変更していくためのサイクル（変化対応サイクル１００−０１）と、障害に対して迅速に対応するためのサイクル（障害対応サイクル１００−０２）とを備えている必要がある。両サイクルにおいて、合意記述データベース（agreement description database）１１０が参照または更新される。なお、以下では、合意記述データベース１１０を「Ｄ−ＡＤＤ」と短縮して呼称する場合がある。

変化対応（change accommodation）サイクル１００−０１は、上流プロセスにおける対象システムのオープンシステムディペンダビリティを担保するために必要とされるプロセスからなるサイクルである。この変化対応サイクル１００−０１は、合意形成（consensus building）プロセス１００−０３と、開発（development）プロセス１００−０４と、説明責任遂行（accountability achievement）プロセス１００−０５の３つのプロセスを定義している。

障害対応（failure response）サイクル１００−０２は、対象システムの運用時に必要とされるプロセスからなるサイクルである。この障害対応サイクル１００−０２は、障害対応プロセス１００−０６と、説明責任遂行プロセス１００−０５の２つのプロセスを定義している。普段は、両サイクルとも対象システムは通常運用状態（ordinary operation）１００−０７にある。

対象システムのディペンダビリティに関する利害関係者を、ＤＥＯＳプロセス１００においては「ステークホルダ」と呼ぶ。ステークホルダとしては、１）サービス・製品の利用者（顧客、社会的インフラの場合は社会全体）、２）サービス・製品の提供者（事業主）、３）システム提供者（設計開発者、保守運用者、ハードウェア供給者）、４）サービス・製品認可者（規制監督官庁）等を想定するが、これに限定されるものではない。

ステークホルダは、時間の経過や環境の変化によって各々の目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化に対し、ステークホルダは熟慮し、相互に合意した上で、適切な時期にシステムの変更を要求する。ＤＥＯＳプロセス１００はこのような要求に対するサイクルとして、上述の変化対応サイクル１００−０１を備える。

対象システムは、不完全さと不確実さに起因する障害を完全に回避することが困難である。障害の予兆を検出した場合には障害を未然に回避するが、不幸にも障害が発生してしまった場合には、迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。ＤＥＯＳプロセス１００では、そのような状況に対応するために上述の障害対応サイクル１００−０２を備える。

合意形成プロセス１００−０３は、要求抽出／リスク分析（requirements elicitation / risk analysis）フェーズ１００−０９と、ステークホルダ合意（stakeholders' agreement）フェーズ１００−１０とから構成される。この合意形成プロセス１００−０３は、目的変化／環境変化イベント（objectives/environment change）１００−１９によって、または、障害対応プロセス１００−０６の結果次第で起動される。

要求抽出／リスク分析フェーズ１００−０９では、組織の行動規範のもと、ビジネスビジョン、ユーザニーズ、ステークホルダの目標、多様なシステム環境、規制などから対象システムに係る要求が抽出される。また、それと同時に、サービス継続（service continuation）シナリオが開発される。要求抽出／リスク分析フェーズ１００−０９の結果は、一連のディペンダビリティ要求である。このディペンダビリティ要求は、文書形式のデータであり、その開発過程での生成物とともに、合意記述データベース１１０に記録され（１００−２０）、後続のプロセスでの利用に備える。

ステークホルダ合意フェーズ１００−１０は、複数のステークホルダによる対象システムにおいて、何を、何故、如何に変更するか、ということに関する議論から始まる。この議論のプロセス、および、その結果としての合意は、後述のＤ−Ｃａｓｅとして論理的に記述される。ステークホルダ合意フェーズ１００−１０は、サービス継続シナリオからの実行可能手続きを生成する。この実行可能手続きは障害対応に利用される。そして、上述の要求抽出／リスク分析フェーズ１００−０９と同様に、このステークホルダ合意フェーズ１００−１０において開発された生成物は、主に文書形式のデータであり、合意記述データベース１１０に記録され（１００−２０）、後続のプロセスでの利用に備えるとともに、前段の要求抽出／リスク分析フェーズ１００−０９での生成物との間の関連リンクが生成される。

開発プロセス１００−０４は、設計フェーズ１００−１１と、実装フェーズ１００−１２と、検証フェーズ１００−１３と、テストフェーズ１００−１４とから構成される。

設計フェーズ１００−１１では、前段の合意形成プロセス１００−０３の結果として合意された要求を、例えば、如何に対象システムに実装し、運用していくかが議論され、必要な仕様書にまとめられる。

実装フェーズ１００−１２では、設計フェーズ１００−１１における仕様書から必要なプログラムコードを記述し、または、必要な技術を実現するプログラムコードを調達し、必要な運用のためのシステムの構築などを行う。

検証フェーズ１００−１３では、実装フェーズ１００−１２の結果が合意形成プロセス１００−０３の結果と矛盾してないかが検査される。プログラムの論理的整合性、プログラミング言語矛盾などが検査される。

テストフェーズ１００−１４では、性能検証のためのベンチマークや耐障害テストなどにより、合意形成プロセス１００−０３におけるステークホルダ合意の通りに対象システムが動作するかが確認される。

これら開発プロセス１００−０４の各フェーズにて開発された生成物は、文書形式のデータや、プログラムコード形式のデータであり、合意記述データベース１１０に記録され（１００−２１）、前段の合意形成プロセス１００−０３にて開発された生成物との間の関連リンクが生成され、後段の説明責任遂行プロセス１００−０５を含む他のプロセスやサイクルでの利用に備える。

障害対応プロセス１００−０６は、通常運用状態１００−０７から起動され、未然回避（failure prevention）フェーズ１００−１５と、迅速対応（responsive action）フェーズ１００−１６と、原因究明（cause analysis）フェーズ１００−１７とから構成される。

未然回避フェーズ１００−１５は、予兆検知／障害発生イベント１００−１８における、特に予兆検知によって起動される。障害の予兆が検知されたことにより、その障害を回避するための必要な対策が実行される。上述の実行可能手続きの実行によってその対策が実行される場合もあり、また、必要な原因究明フェーズ１００−１７を経て合意形成プロセス１００−０３が起動されてステークホルダによる対策が実行される場合もある。どちらの場合も、合意記述データベース１１０がアクセスされる（１００−２４）。この実行可能手続きは合意記述データベース１１０から必要に応じて対象システムにデプロイされる。また、合意形成プロセス１００−０３が起動された場合にも、合意記述データベース１１０がアクセスされ（１００−２４）、必要な対策が同定される。

一方、迅速対応フェーズ１００−１６は、予兆検知／障害発生（anomaly detection / failure）イベント１００−１８における、特に障害発生によって起動され、その障害から対象システムを通常運用状態１００−０７に回復させる対策が実行される。未然回避フェーズ１００−１５と同様に、実行可能手続の実行によってその対策が実行される場合もあり、また、必要な原因究明フェーズ１００−１７を経て合意形成プロセス１００−０３が起動されてステークホルダによる対策が実行される場合もある。どちらの場合も、合意記述データベース１１０がアクセスされる（１００−２４）。この実行可能手続きは合意記述データベース１１０から必要に応じて対象システムにデプロイされる。また、合意形成プロセス１００−０３が起動された場合にも、合意記述データベース１１０がアクセスされ（１００−２４）、必要な対策が同定される。

通常運用状態１００−０７は、対象システムが通常の運用状態にあることを示している。この通常運用状態１００−０７は、対象システムがステークホルダ間で合意されたサービスレベル変動許容範囲（in-operation range）から大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクル１００−０１は、通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクル１００−０２も、通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、サービスレベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。または、一部の機能を縮退してサービスを継続している場合もある。しかしながら、サービスの提供が完全に停止されてしまう場合もある。

通常運用状態１００−０７において実行されるプロセスには、日常的な動作記録の点検、プロセスの定期的な見直しや改善、要員の訓練、しつけおよび教育など、継続的なディペンダビリティ向上活動が含まれる。システムの稼働状況を記録し、日々点検することにより、保守担当者や運用担当者が何かの兆候をそこから見出すことができる可能性がある。また、システムのメモリ資源を常にクリーンな状態にすることも、非常に有効な日常保守または改善活動である。または、積極的に予行を行うことも有効である。障害は、ある時間が経過してある状態に達した時に発生する。そうであれば、時間を先に経過させると障害の発生を事前に知ることができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかはその時の状況による。

この通常運用状態１００−０７においても合意記述データベース１１０がアクセスされる（１００−２３）。対象システムがサービスレベル許容範囲にある状態であるかどうかを監視するための実行可能手続きは当該データベースから対象システムにデプロイされている。また、対象システムにて取得されている各種ログについて、必要な分が抽出され、適切な形式に変換され、合意記述データベース１１０に送られるというＥＴＬ（Extract / Transform / Load）処理によっても、対象システムの状態がサービスレベル許容範囲にあるかが判断される。

説明責任遂行プロセス１００−０５では、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者および社会に対し、障害状況、迅速対応および今後の見通しなど説明する。また、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか（変化するのか）を説明する。日常のサービス遂行状況や、設計開発／保守運用プロセスに関する説明が必要なときもこれに対応する。これらは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。説明責任遂行の為に必要な情報は、合意記述データベース１１０に記録されているため、必要に応じてアクセスされる（１００−２２）。

＜合意記述データベース（Ｄ−ＡＤＤ）の概要＞
図２は、本実施の形態に係る合意記述データベース１１０の構成例の概略を示す機能ブロック図である。この合意記述データベース１１０は、請求の範囲に記載のデータベースシステムの一例である。

合意記述データベース１１０は、対象システム２１０とネットワーク２２０を介して結ばれている。対象システム２１０は、別個の２台以上のコンピュータから構成されるシステムであってもよい。２台以上のコンピュータから構成される場合には、各コンピュータはネットワーク２２０によって接続され得る。この実施の形態におけるネットワーク２２０は、専用回線であってもよく、インターネットを含む公衆回線であってもよく、公衆回線上にＶＰＮ技術を用いて仮想的な専用回線を構築したものであってもよく、また、１台のコンピュータ内部のＯＳの提供する通信回線であってもよい。以下では、特に断らない限りネットワークを上述のように定義する。

合意記述データベース１１０は、ルールエンジン部２００−０１、モデル処理部２００−０２、永続化部２００−０３、ハイブリッドデータベース部２００−０４、および、基本ツール部２００−０５から構成される。

モデル処理部２００−０２は、１以上のデータモデルを定義する。変化対応サイクル１００−０１、障害対応サイクル１００−０２、および、通常運用状態１００−０７において開発され、または生成された生成物は、合意記述データベース１１０に記録される際に、モデル処理部２００−０２において処理され、管理される。すなわち、このモデル処理部２００−０２は、対象システムのライフサイクル全般に亘って生成される複数の生成物に基づいて複数のモデルを処理する。

ルールエンジン部２００−０１は、対象システムのオープンシステムディペンダビリティを維持するためのルールを管理するとともに、そのために必要な処理をモデル処理部２００−０２において管理されているデータモデルに従って実行する。すなわち、このルールエンジン部２００−０１は、複数のモデルに基づいて複数の生成物の関係および制約に関する条件およびその条件に応じた処理をルールとして定義する。

永続化部２００−０３は、モデル処理部２００−０２において管理されているデータモデルに従って、上述の生成物を下位のハイブリッドデータベース２００−０４に記録する。

基本ツール部２００−０５は、他部の機能を利用して、合意記述データベース１１０を利用するための基本的ツールを提供する。各部の機能の詳細は後述する。

＜ハードウェア構成＞
図３は、本実施の形態に係る合意記述データベース１１０および対象システム２１０のハードウェア構成例を示す図である。最も基本的な構成としては、合意記述データベース１１０および対象システム２１０は、命令バスおよびデータバスによって接続された演算装置３００−０１と、制御装置３００−０２と、メモリ装置３００−０３と、入出力装置３００−０４とを備えた電子計算機である。

入出力装置３００−０４から入力されたビットデータの情報に基づいて、演算装置３００−０１において、算術演算、論理演算、比較演算、シフト演算などが実行される。実行されたデータは、必要に応じて、メモリ装置３００−０３に記憶され、入出力装置３００−０４から出力される。これら一連の処理は、メモリ装置３００−０３に記憶されたソフトウェアプログラムに従って、制御装置３００−０２によって制御される。本実施の形態における合意記述データベース１１０および対象システム２１０は、上述のコンピュータとしての基本機能を備えたハードウェアであり、オペレーティングシステムやデバイスドライバ、ミドルウェア、アプリケーションソフトウェアといった複数のプログラムによって制御される。

＜合意記述データベース（Ｄ−ＡＤＤ）の機能構成＞
図４は、本実施の形態における合意記述データベース１１０の機能構成例を示す図である。

ここでは、ＤＥＯＳプロセス１００における通常運用状態１００−０７、変化対応サイクル１００−０１、障害対応サイクル１００−０２、および、説明責任遂行プロセス１００−０５から説明する。まず、通常運用状態１００−０７は、対象システム２１０を通常運用状態に維持する活動である。対象システム２１０は、ステークホルダによって合意され、責任者によって承認されたＤ−Ｃａｓｅと附随する実行可能手続きにより様々の記録が取られている。それらの活動や記録からは、生成物₃２５０−１３が生み出される。

ビジネス環境の変化等の理由で対象システムが通常運用状態１００−０７を維持できなくなった時には、変化対応サイクル１００−０１が始まる。ここでは、合意記述データベース１１０の構成要素であって基本ツール部２００−０５に含まれる合意形成支援ツール２５０−０１を利用して、ステークホルダ間でその変化への対応策が議論され、ソリューションが合意され、生成物₁２５０−１１となる。この際に、生成物₃２５０−１３のどの項目がその変化に対して脆弱であったか検査され、生成物₁２５０−１１内のソリューションと関連付けられる。

ソリューションに基づいて対象システム２１０が更新されると、説明責任遂行プロセス１００−０５が開始される。ここでは、どのような事由により、どのようなソリューションが開発され、対象システムが更新されたかの情報が、基本ツール部２００−０５の構成要素である説明責任遂行支援ツール２５０−０２を用いて、生成物₂２５０−１２としてまとめられる。

これらの生成物は、モデル処理部２００−０２において複数のモデルに分解され、永続化部２００−０３に上述のように記録され、変化または変更や関連性がルールエンジン部２００−０１において上述のように処理される。このようにして、この例における生成物₃２５０−１３に記載の脆弱性が、生成物₁２５０−１１に記載のソリューションと関連しており、そのソリューションが、生成物₂２５０−１２に記載の対象システム２１０の更新内容に関連付けられる。

＜合意記述データベース（Ｄ−ＡＤＤ）の構成＞
図５は、本実施の形態における合意記述データベース１１０の内部構成例を示す図である。この合意記述データベース１１０の中核を構成するのが中核部（Ｃｏｒｅ）４００−０１である。この中核部４００−０１は、ルールエンジン部２００−０１、モデル処理部２００−０２、永続化部（Ｐｅｒｓｉｓｔｅｎｃｅ）２００−０３、および、ＡＣ ＡＰＩ部４００−１０から構成される。

ルールエンジン部２００−０１は、ルール処理部（Ｒｕｌｅ Ｐｒｏｃｅｓｓｉｎｇ）４００−０５と、スクリプト処理部（Ｓｃｒｉｐｔ Ｐｒｏｃｅｓｓｉｎｇ）４００−０６とを含む。ルール処理部４００−０５は、複数のルール記述（ａ Ｒｕｌｅ）４００−０７を処理する。スクリプト処理部４００−０６は、複数のスクリプト記述（ａ Ｓｃｒｉｐｔ）４００−０８を処理する。

モデル処理部２００−０２は、複数のモデル記述（ａ Ｍｏｄｅｌ）４００−０９を処理する。複数のモデル記述４００−０９の各々は、ルールエンジン部２００−０１において計算されるデータのモデルを定義するとともに、永続化部２００−０３に記録するデータのモデルを定義する。

ＡＣ ＡＰＩ部４００−１０は、ルールエンジン部２００−０１における処理に必要な権限モデルを管理する。

永続化部２００−０３は、下位のハイブリッドデータベース２００−０４に対するアクセスを抽象化するものである。

ハイブリッドデータベース２００−０４は、索引部（Ｉｎｄｅｘｉｎｇ）４００−１３、グラフデータベース（Ｇｒａｐｈ ＤＢ）４００−１４、ＸＭＬデータベース（ＸＭＬ ＢＤ）４００−１５、および、文書データベース（Ｄｏｃｕｍｅｎｔ ＤＢ）４００−１６から構成される。索引部４００−１３は、下位のデータベース（４００−１４、４００−１５および４００−１６）に対して索引処理を実行する。

なお、上述の構成例は、ＤＥＯＳ実行環境（Ｄ−ＲＥ）４００−２１上で稼働するように構成されるが、他の構成手段を採ってもよい。

図６は、本実施の形態における合意記述データベース１１０のＡｒｃｈｉＭａｔｅ（登録商標）形式による表現例を示す図である。同図は、全てＡｒｃｈｉＭａｔｅ（登録商標）仕様に定められるアプリケーション層の記述のみを描いている。なお、ＡｒｃｈｉＭａｔｅ（登録商標）の仕様については、以下のＵＲＬから参照可能である（http://www.opengroup.org/subjectareas/enterprise/archimate）。

基本ツール群を含むアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）４１０−０１は、Ｄ−ＡＤＤ ＡＰＩ４１０−０３を経由して、Ｄ−ＡＤＤ（合意記述データベース１１０）にアクセスする。コンソールＡＰＩ（Ｃｏｎｓｏｌｅ ＡＰＩ）４１０−０４は、Ｄ−ＡＤＤ ＡＰＩ４１０−０３を拡張し、ＳＤＫ等（ＳＤＫ ｅｔｃ．）４１０−０２の合意記述データベース１１０を構成するためのツール群からアクセスするためのＡＰＩを定義する。

Ｄ−ＡＤＤ ＡＰＩ４１０−０３は、図５のルール処理部４００−０５、スクリプト処理部４００−０６およびモデル処理部２００−０２に各々対応する、Ｒｕｌｅ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０５、Ｓｃｒｉｐｔ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０６およびＭｏｄｅｌ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０７によって実現される。

Ｒｕｌｅ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０５は、複数のデータオブジェクト（図中では「ａ Ｒｕｌｅ」）４１０−０８にアクセスする（４１０−１６）。Ｒｕｌｅ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０５は、データオブジェクト４１０−０８に記載されたルールを解釈し、条件が真のルールに記載されたアクションを実行し、そのデータオブジェクトに関連したデータオブジェクト（図中では「ａ Ｓｃｒｉｐｔ」）４１０−２１をＳｃｒｉｐｔ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０６で実行する。

Ｓｃｒｉｐｔ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０６は、複数のデータオブジェクト（図中では「ａ Ｓｃｒｉｐｔ」）４１０−２１や４１０−２２に記載の処理を実行する（４１０−２０等）。

Ｍｏｄｅｌ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０７は、複数のデータオブジェクト（図中では「ａ Ｍｏｄｅｌ」）４１０−０９にアクセスする（４１０−１７）。これらデータオブジェクト４１０−０９はデータ型であり、複数のインスタンス４１０−１０のデータ型を決定する（４１０−１８）。これらインスタンス４１０−１０は、Ｒｕｌｅ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０５、Ｓｃｒｉｐｔ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０６およびＭｏｄｅｌ Ｐｒｏｃｅｓｓｉｎｇコンポーネント４１０−０７からアクセスされる（４１０−１９）。

Ｐｅｒｓｉｓｔｅｎｃｅインターフェース４１０−１１は、永続化部２００−０３に対応する。このＰｅｒｓｉｓｔｅｎｃｅインターフェース４１０−１１は、Ｉｎｄｅｘｉｎｇサービス４１０−１２、Ｇｒａｐｈ ＤＢサービス４１０−１３、ＸＭＬ ＤＢサービス４１０−１４およびＤｏｃｕｍｅｎｔ ＤＢサービス４１０−１５から構成されるハイブリッドデータベースを利用して、抽象化されたインターフェースを定義している。なお、上述の構成以外の構成方法によって合意記述データベース１１０を構成してもよい。

図７は、本実施の形態における合意記述データベース１１０内部に記録されるデータ間の関係の概略を示す図である。データは、ベース層５００−０１またはメタ層５１０−０１に属する。本実施の形態において、ベース層５００−０１は、データが独立して存在している論理空間である。一方、メタ層５１０−０１は、ベース層５００−０１のデータの関係・制約に関するデータが存在している論理空間である。なお、ベース層５００−０１のデータには他のデータへの参照を含んでいるデータもあり、全ての関係・制約に関するデータがメタ層５１０−０１に存在しているとは限らない。本実施の形態では、特にディペンダビリティ要件に関するデータをメタ層５１０−０１に配置するが、実施に当たっては他の形態をとってもよい。

ベース層５００−０１には、上述のＤＥＯＳプロセス１００の実行によって、各種の文書データ（要求５００−０２、仕様５００−０３、設計５００−０４、運用５００−０６、等）、プログラムデータであるコード５００−０６、開発中結果５００−０７、テスト結果５００−０８、運用ログデータ５００−０９等が生成される。それらは、Ｄ−Ｃａｓｅ（５００−１０、５００−１１、５００−１２）の付帯文書として永続化部２００−０３に記録される。また、これら複数の付帯文書は後述する関連リンクによって繋がっている。

一方で、どのデータがどのように繋がっているか、繋がりの有効期限、データの特性、データの制約、等々の組織固有の行動規範５１０−０２（ビジネスビジョンや組織内規）や規制５１０−０３に影響を受けるデータを、ここでは関係・制約記述データ（５１０−０４、５１０−０５、５１０−０６）とよび、これら関係・制約データをメタ層５１０−０１に配置する。同図において、関係・制約記述データ５１０−０４は、要求５００−０２と、仕様５００−０３と、Ｄ−Ｃａｓｅ５００−１０と、コード５００−０６との関係および制約に関する。関係・制約記述データ５１０−０５は、Ｄ−Ｃａｓｅ５００−１２と、運用５００−０５と、運用ログ５００−０９との関係および制約に関する。関係・制約記述データ５１０−０６は、Ｄ−Ｃａｓｅ５００−１１と、開発中結果５００−０７と、テスト結果５００−０８との関係および制約に関する。

＜ベース層における関連性＞
図８は、本実施の形態のベース層５００−０１における各種データの関連性を示す図である。この図は本実施の形態における一例であり、これに限定されるものではない。この図では、ディペンダビリティに関するステークホルダからの要求を記述したＤ−Ｃａｓｅ６００−０１を中心として、その要求の詳細記述６００−０４と、要求詳細記述６００−０４に基づく仕様６００−０５と、テスト結果６００−０３とが関連しているものとして図示している。

プログラムコード６００−０６は、仕様６００−０５に基づいて開発された成果物であるため、関連がある。プログラムコード６００−０６は、テスト結果６００−０３と関連がある。Ｄ−Ｃａｓｅ６００−０２は、運用に関するステークホルダ要求を記載している。このＤ−Ｃａｓｅ６００−０２は、運用手順書６００−０７および運用ログ６００−０８と関連がある。運用ログ６００−０８は、運用手順書６００−０７に基づいてログを記録する。運用手順書６００−０７は、コード６００−０６に基づいて運用する。これら文書は全てステークホルダによって合意された状態（６１０−０１）の文書である。これらは、ＤＥＯＳプロセス１００を構成する通常運用状態１００−０７からアクセスされるのみならず、変化対応サイクル１００−０１および障害対応サイクル１００−０２からもアクセスされる。

図９は、本実施の形態のモデル処理部２００−０２における表現例を示す図である。ここでは、図８に示した状態を想定している。図８のＤ−Ｃａｓｅ６００−０１に対応するモデルは、ＵＭＬ形式のモデルによって合意記述データベース１１０に記録される際には、点線円６２０−０１で示した複数のノードとして表現される。ここでは、ゴール６２０−０６、コンテキスト６２０−０７、ストラテジ６２０−０８、ゴール６２０−０９、ゴール６２０−１０、エビデンス６１０−１１および６２０−１２が、Ｄ−Ｃａｓｅ表現の木構造を維持した状態で合意記述データベース１１０に記録される。

要求６００−０４は、一般に複数存在するため、ここでは点線円６２０−０２で示した３ノードとして表現される。この要求６００−０４は、要求₁６２０−１３、要求₂６２０−１４および要求₃６２０−１５から構成される。この要求６００−０４は、仕様６００−０５に繋がっており、要求６００−０４に基づいて仕様６００−０５が開発された旨を示している。

仕様６００−０５は、仕様₁６２０−１６および仕様₂６２０−１７から構成され、仕様₁６２０−１６は要求₁６２０−１３と、仕様₂６２０−１７は要求₃６２０−１５とそれぞれ関係している。図８において仕様６００−０５に基づいてコード６００−０６が開発され、コード６００−０６を用いてテスト結果６００−０３が作成されているため、図９では仕様₁６２０−１６と仕様₂６２０−１７とともにコード６２０−１８が関係するように合意記述データベース１１０に記録される。コード６２０−１８は、テスト結果６２０−１９と関係している。

また、図８におけるＤ−Ｃａｓｅ６００−０２は、図９では点線円６２０−０４を構成するゴール６２０−２０とエビデンス６２０−２１として表現される。図８ではＤ−Ｃａｓｅ６００−０２に基づいて運用６００−０７文書が開発され、それに基づいて運用ログが記録される。図９ではゴール６２０−２０は運用₁６２０−２２と関係し、運用₂６２０−２３は運用ログ６２０−２４と関係するように合意記述データベース１１０に記録される。そして、運用ログ６２０−２４は、エビデンス６２０−２１に関連付けられて合意記述データベース１１０に記録される。

図１０は、本実施の形態におけるＤ−Ｃａｓｅを記録するモデルの一例をＵＭＬ形式で示す図である。Ｄ−Ｃａｓｅ表現の構成要素は、Ｇｏａｌクラス６３０−０５、Ｓｔｒａｔｅｇｙクラス６３０−０６、Ｃｏｎｔｅｘｔクラス６３０−０７、Ｕｎｄｅｖｅｌｏｐｅｄクラス６３０−０８、Ｅｖｉｄｅｎｃｅクラス６３０−０９、および、Ｅｖｉｄｅｎｃｅクラス６３０−０９をサブクラスに持つＭｏｎｉｔｏｒクラス６３０−１０である。これらのクラスは、全てＮｏｄｅクラス６３０−０３のサブクラスであり、ＮｏｄｅＳｅｔクラス６３０−０２に集約される。ＮｏｄｅＳｅｔクラスは、ＤＣａｓｅクラス６３０−０１に集約されるとともに、Ｎｏｄｅクラス６３０−０３を集約している。Ｄ−Ｃａｓｅの付帯文書は、ＤＣａｓｅＤｏｃｕｍｅｎｔクラス６３０−０４下に特殊化される。この図では付帯文書のクラス図は示していない。

＜メタ層における関連性＞
図１１は、本実施の形態のメタ層５１０−０１における各種データの関連性を示す図である。ここでは、ある対象システムＡが２個のソフトウェア部品を利用している状況を想定している。対象システムＡのＤ−Ｃａｓｅ７００−０２、その部品ＢのＤ−Ｃａｓｅ７００−０３と部品ＣのＤ−Ｃａｓｅ７００−０４が存在している。それぞれ対象システムＡの部品であるため、部品Ｂと部品ＣのＤ−Ｃａｓｅ（７００−０３および７００−０４）は、対象システムＡのＤ−Ｃａｓｅ７００−０２とは独立していて、それらの間に何らディペンダビリティ要求を記述した文書（Ｄ−Ｃａｓｅはその一例）が存在しないことになる。本実施の形態では、このような関係・制約を記述するデータを導入し、特にディペンダビリティ要求をＤ−Ｃａｓｅ形式で記述したデータを「メタＤ−Ｃａｓｅ」と呼ぶ。この図では、メタＤ−Ｃａｓｅ７００−０１がそれに該当し、対象システムＡとその部品ＢおよびＣのＤ−Ｃａｓｅ間の関係を記述する。

図１２は、本実施の形態のメタ層５１０−０１における各種データの関連性を示す他の図である。ここでは、対象システムＡが部品供給者から２個のソフトウェア部品の提供を受けて対象システムを構築している状況を想定している。対象システムＡのＤ−Ｃａｓｅ７１０−０２には、提供を受ける２個の部品のＤ−Ｃａｓｅ（７１０−０３および７１０−０４）への依存関係が存在し、ここでは、対象システムＡのＤ−Ｃａｓｅ７１０−０２のあるディペンダビリティ要求を満たすエビデンスに関連付けている。この例の場合には、２個の部品各々に対するディペンダビリティ要求は対象システムＡのＤ−Ｃａｓｅに記述されている。しかし、３者（７１０−０２、７１０−０３および７１０−０４）のＤ−Ｃａｓｅ間の関係、例えば、部品間の処理順序の制約からくるディペンダビリティ要求、または、部品間での相互依存の制約からくるディペンダビリティ要求、等の３以上のＤ−Ｃａｓｅ間の関係はメタＤ−Ｃａｓｅ７１０−０１に記述する。

図１３は、本実施の形態のメタ層５１０−０１におけるメタＤ−Ｃａｓｅの記述例を示す図である。トップゴールＧ＿１は、「ａｐｐ＿１はｓｅｒｖ＿１に依存している」（７２０−０１）である。ここで、ａｐｐ＿１は単純なチャットアプリケーションであり、ｓｅｒｖ＿１はそのアプリケーションを実行するために既存のクラウドサービスにデプロイされた実行環境である。クラウドサービス業者との間にはＳＬＡ（Service Level Agreement）が締結されている。この状況はコンテキストＣ＿１に記載され（７２０−０２）、そこにはベース層５００−０１に存在するａｐｐ＿１のＤ−Ｃａｓｅ、ｓｅｒｖ＿１のＤ−Ｃａｓｅ、および、ＳＬＡへのリンクが記載されている。

これらの情報は、合意記述データベース１１０内部ではモデル処理部２００−０２において対応するモデル定義に従って、データとその関連性が記録されている。トップゴールＧ＿１は、ストラテジＳ＿１ノードにおいて「ＳＬＡに従って議論を分解」（７２０−０３）している。

サブゴールは３つ存在する。サブゴールＧ＿１．１は「どのようなエラーが返されるか同定されている」（７２０−０４）ことであり、サブゴールＧ＿１．２は「反応時間は１０ｍｓ以内である」（７２０−０５）ことであり、サブゴールＧ＿１．３は「ＳＬＡが有効期限内である」（７２０−０６）ことである。各々にエビデンスが存在している。エビデンスＥ＿１は「エラーが返された時の処理が同定されている」（７２０−０７）であり、テスト結果の文書が付帯することによってサブゴールＧ＿１．１を満たす。

エビデンスＭ＿１はＤ−Ｃａｓｅモニタリングノードであり、「反応時間を計測するスクリプトが導入され稼働されている」（７２０−０８）とあり、対応するスクリプトが導入され実行され、その結果を判断することによって、サブゴールＧ＿１．２が満たされているかが判明する。エビデンスＭ＿２も同様に、Ｄ−Ｃａｓｅモニタリングノードであり、「ＳＬＡの有効期限を確認するスクリプトが導入され稼働している」とあり、対応するスクリプトが導入され実行され、その結果を判断することによって、サブゴールＧ＿１．３が満たされているかが判明する。

＜モデル処理部とルールエンジン部＞
図１４は、本実施の形態におけるモデル処理部２００−０２およびルールエンジン部２００−０１の機能構成例を示す図である。モデル処理部２００−０２は、モデル定義部２３０−０１、モデルインスタンス導入部２３０−０２、モデル変更部２３０−０３、モデル記録部２３０−０４、および、メタモデル処理部２３０−０５の５つの機能ブロックから構成される。ルールエンジン部２００−０１は、条件評価準備部２３０−１０、条件評価部２３０−１１、ルール順序化部２３０−１２、スクリプト抽出部２３０−１３、および、スクリプト実行部２３０−１４の５つの機能ブロックから構成される。ルールエンジン部２００−０１において、条件評価準備部２３０−１０、条件評価部２３０−１１、および、ルール順序化部２３０−１２は、上述のルール処理部４００−０５に対応する。そして、スクリプト抽出部２３０−１３、および、スクリプト実行部２３０−１４は、上述のスクリプト処理部４００−０６に対応する。

モデル定義部２３０−０１は、新しいモデルを定義する際に利用される。例えば、図１０に示したＤ−Ｃａｓｅモデルを合意記述データベース１１０に定義するのは、モデル定義部２３０−０１の機能である。このモデル定義部２３０−０１は、新しいモデルを定義すると、ルールエンジン部２００−０１を構成する条件評価準備部２３０−１０に対して、ルール条件の準備を指示する。例えば、図１０に示したＤ−Ｃａｓｅモデルの場合には、新しいＤ−Ｃａｓｅ記述の合意記述データベース１１０への登録を契機としたＤ−Ｃａｓｅモデルインスタンスを生成するルール、Ｄ−Ｃａｓｅが変更された時のルール、Ｄ−Ｃａｓｅエビデンスノードの充足を確認するルール、Ｄ−Ｃａｓｅモニタリングノードに附随した実行可能手続きの署名を検証するルール、等々のＤ−Ｃａｓｅの妥当性を検証するための複数のルールが、ルールエンジン部２００−０１のルール処理部４００−０５に導入される。

モデルインスタンス導入部２３０−０２は、合意記述データベース１１０に新しい文書データが記録される際に、その文書データのモデルを決定し、モデル処理部２００−０２にモデルインスタンスとしてその文書データを読み込み、モデル記録部２３０−０４を利用して、そのモデルインスタンスを永続化部２００−０３から記録する。その後、条件評価部２３０−１１に対してルール条件の評価を依頼する。

条件評価部２３０−１１は、該当するルールを抽出し、ルール順序化部２３０−１２において２以上の該当ルールが抽出された際の実行順序を決定する。並列処理が構成されている場合には、ルールは並列に実行される。順序が決定されたルールについて、スクリプト抽出部２３０−１３によってスクリプトが抽出される。そして、その抽出されたスクリプトがスクリプト実行部２３０−１４によって実行される。

モデル変更部２３０−０３は、モデル記録部２３０−０４に存在するモデルを変更または更新する機能を有する。例えば、図１０に示したＤ−Ｃａｓｅモデルのインスタンスを変更する際には、柳澤らの文献（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）に記載の手法を用いてもよい。この手法を用いると、合意形成プロセス１００−０３の進行に従ってＤ−Ｃａｓｅのノードがモデル変更部２３０−０３によって追加され、モデル記録部２３０−０４によって記録される。

モデル記録部２３０−０４は、永続化部２００−０３を通してアクセスされるハイブリッドデータベース２００−０４からはキャッシュに見える。すなわち、主メモリ上のモデルやモデルインスタンス、ルールはより広大なメモリ空間を有するハイブリッドデータベース２００−０４の情報空間の一部が写像され、モデル記録部２３０−０４は写像を管理している。

メタモデル処理部２３０−０５は、メタＤ−Ｃａｓｅを処理する機能ブロックである。図１０に示したＤ−ＣａｓｅモデルにおけるＮｏｄｅクラス６３０−０３に定義されたメタ属性６３０−２０が"ｎｕｌｌ"で無い場合、すなわち、あるＤ−Ｃａｓｅに対してメタＤ−Ｃａｓｅが存在する場合、メタＤ−Ｃａｓｅを評価し、ベース層のＤ−Ｃａｓｅと互換性があるか検証される。例えば、図１３に示したメタＤ−Ｃａｓｅの場合には、そのＤ−Ｃａｓｅがａｐｐ＿１に関するＤ−Ｃａｓｅであり、ａｐｐ＿１はｓｅｒｖ＿１に関するＤ−Ｃａｓｅを必要としている。メタモデル処理部２３０−０５は、必要な全てのＤ−Ｃａｓｅの存在を確認し、メタＤ−Ｃａｓｅに記載されているエビデンスノードの妥当性を確認する。全ての妥当性が確認されれば、メタＤ−Ｃａｓｅに対応するベース層のＤ−Ｃａｓｅは互換であるとみなされ、必要なディペンダビリティ要求を満たしていると判断することができる。

図１５は、本実施の形態のルール処理部４００−０５におけるルール処理の例を示す図である。ここでは、ルール処理部４００−０５で処理されるルールに関するＵＭＬクラス図の例を示している。ルール（図中では「Ｒｕｌｅ」）８００−０１は、条件部（図中では「ＲｕｌｅＣｏｎｄｉｔｉｏｎ」）８００−０２、アクション部（図中では「ＲｕｌｅＡｃｔｉｏｎ」）８００−０３、結果記録部（図中では「ＲｕｌｅＥｘｐｅｒｉｅｎｃｅ」）８００−０４、および、ルール文脈部（図中では「ＲｕｌｅＣｏｎｅｘｔ」）８００−０５から構成される。本実施の形態では、複数のルールを１グループとして取り扱うことができるようにルール集合を導入した。これにより、グループ内のルールの評価順序を指定し、アトミック処理を構成し、権限管理の単位とすることが可能となる。ここでは、ルール集合をＲｕｌｅＳｅｔクラス８００−０８として示す。ルールは１以上のルール集合に含まれる。ルール集合には付帯ドキュメント（図中では「ＲｕｌｅＳｅｔＤｏｃｕｍｅｎｔ」）８００−０９が関連付けられる。

図１６は、本実施の形態のルール処理部４００−０５におけるルール記述の例を示す図である。ここでは、１個のルールセット８１０−０１が定義されている。名称は「ＳｙｓｔｅｍＬｏａｄＣｏｎｄｉｔｉｏｎｅｒ」であり、Ｄ−Ｃａｓｅモニタリングノードに対応するルールとして例示する。ルールセット８１０−０１には２個のルール８１０−０２および８１０−０５が定義されている。ルール８１０−０２は、メモリ残量が既定値（in-operation range）よりも少なくなったときに真となる。ルール８１０−０５は、ＣＰＵ使用率が規定値よりも少なくなったときに真となる。この条件が８１０−０３および８１０−０６に示され、条件が真となった場合のアクションが８１０−０４および８１０−０７に示される。

＜データの永続化＞
図１７は、本実施の形態におけるデータの永続化の例を示す図である。ここでは３つのモデルが示されている。Ｄ−Ｃａｓｅノードのモデル９００−０１、付帯情報のモデル９００−０２およびログ等のデータのモデル９００−０３である。これらのモデルは、永続化部２００−０３を経由して下位のハイブリッドデータベース２００−０４に記録される。記録に際して、まず、Ｉｎｄｅｘｉｎｇ４００−１３によって索引が記録される（９００−０９）。同時に、各モデルはモデルのクラスによって記録されるデータベースが決定される。例えば、モデル９００−０１のインスタンスは、Ｇｒａｐｈ ＤＢ４００−１４にグラフ構造９００−１１として記録される。付帯情報９００−０２のモデルは、そのインスタンスがＸＭＬ ＤＢ４００−１５にタグ付きデータ９００−１２として記録される。ログ等のモデル９００−０３は、そのインスタンスがＤｏｃｕｍｅｎｔ ＤＢ４００−１６に非構造データ９００−１３として記録される（９００−１０）。

また、上述の条件部とプロシジャ部から構成されたルール９００−０４が１つ描かれている。ルール内の条件部（図中では「ｃｏｎｄ．」）はモデルを参照できる。ここでは、ルール９００−０４の条件部は、モデル９００−０１を参照している。条件部が真である場合には、プロシジャ部（図中では「ｐｒｏｃ．」）に関連付けられたスクリプトが実行される。この図では、ルール９００−０４の条件部が真である場合には、スクリプト９００−０５が実行される。その結果、データを更新してもよい。この図では、データ９００−１３を更新している（９００−０７）。更新されたデータはモデルに反映される。この図ではデータ９００−１３の更新の反映（９００−０８）により、モデル９００−０３が変化する。これらの処理は並列処理を行うことによって高速化することが可能である。

＜合意記述データベースの動作＞
図１８は、本実施の形態に係る合意記述データベース１１０の要部の機能構成例を示す図である。また、図１９は、本実施の形態に係る合意記述データベース１１０における処理手順例を示す図である。以下の処理は、ＤＥＯＳプロセス１００を実行する過程で生成された全ての生成物に対して実行される。

ＤＥＯＳプロセス１００を実行する過程で生成物が生成されると、その生成物はモデル処理部２００−０２に入力される（パス８１１）（ステップＳ９１１）。すなわち、ＤＥＯＳプロセス１００の実行の過程で利用される、合意形成支援ツール２５０−０１、説明責任遂行ツール２５０−０２等の基本ツール部２００−０５からの出力が、生成物として合意記述データベース１１０にモデルインスタンス導入部２３０−０２を利用して入力される。

次に、モデル処理部２００−０２によって、生成物に対応するモデルが永続化部２００−０３に存在するか否かが調べられる（ステップＳ９１２）。存在しない場合には（ステップＳ９１２：Ｎｏ）、モデル定義部２３０−０１が、新しいモデルを定義して（ステップＳ９１３）、そのモデルに対応するルールをルールエンジン部２００−０１の条件評価準備部２３０−１０に入力する（パス８２１）（ステップＳ９１４）。ここで、ルールは、複数の生成物の関係および制約に関する条件およびその条件に応じた処理を表す。条件評価準備部２３０−１０は、モデルに附随するルールおよびそのルールに対応するスクリプトを定義して、モデル記録部２３０−０４に供給する（パス８２２）。モデル記録部２３０−０４は、永続化部２００−０３のインターフェースを利用して（パス８２３）、条件評価準備部２３０−１０から供給されたルールおよびスクリプトを、文書データベース４００−１６に記録する（パス８５１）。

モデルインスタンス導入部２３０−０２は、永続化部２００−０３のインターフェースを利用して（パス８１２）、文書データベース４００−１６に生成物を記録する（パス８５１）（ステップＳ９１５）。また、モデルインスタンス導入部２３０−０２は、生成物から対応するモデルに従った構造を構造データとして抽出して、永続化部２００−０３のインターフェースを利用して（パス８１３）、抽出された構造データをＸＭＬデータベース４００−１５に記録する（パス８５２）（ステップＳ９１５）。さらに、モデルインスタンス導入部２３０−０２は、生成物に対応するモデルと他のモデルとの関係を示す関係データを抽出して、永続化部２００−０３のインターフェースを利用して（パス８１４）、抽出された関係データをグラフデータベース４００−１４に記録する（パス８５３）（ステップＳ９１５）。なお、これらの処理において、永続化部２００−０３が各種データベースにアクセスする際には、同時に索引部４００−１３にインデクスが記録される（パス８５４）。

条件評価部２３０−１１は、生成物から抽出されたモデルに附随したルールを評価して、発火条件を検査することにより、発火すべき（処理対象となる）ルールを抽出して、ルール順序化部２３０−１２に供給する（パス８３２）（ステップＳ９１６）。その際、永続化部２００−０３のインターフェースを利用して（パス８３１）、そのモデルに関連するモデルがグラフデータベース４００−１４において検索され（パス８５３）、関連するモデルに附随するルールが文書データベース４００−１６から取り出される（パス８５１）。

ルール順序化部２３０−１２は、供給された複数のルールの発火順序を決定して、スクリプト抽出部２３０−１３は、それぞれのルールに対応するスクリプトを抽出する（パス８３３）。すなわち、これによってスクリプトの実行順序が決定される（ステップＳ９１７）。このようにして決定された実行順序に従って、それらスクリプトをスクリプト実行部２３０−１４が実行する（パス８３４）（ステップＳ９１８）。

モデルにメタモデルが附随しているときには（ステップＳ９１９：Ｙｅｓ）、メタモデル処理部２３０−０５は、そのメタモデルの関係および制約の条件を検証して、充足処理を実行する（ステップＳ９２１）。メタモデル処理部２３０−０５は、その過程で、必要なデータを永続化部２００−０３のインターフェースを利用して（パス８４１）、モデルは文書データベース４００−１６から（パス８５１）、構造データはＸＭＬデータベース４００−１５から（パス８５２）、関係データはグラフデータベース４００−１４から（パス８５３）、それぞれ取得する。また、その過程で、モデルの変更が必要な場合には（ステップＳ９２２：Ｙｅｓ）、モデル変更部２３０−０３がモデルの変更を行う（ステップＳ９２３）。変更されたモデルは、モデル記録部２３０−０４に供給され（パス８４２）、永続化部２００−０３のインターフェースを利用して（パス８２３）、文書データベース４００−１６、ＸＭＬデータベース４００−１５、または、グラフデータベース４００−１４の何れかに記録される（パス８５１乃至８５３）。

このように、本発明の実施の形態によれば、システム規模の拡大や複雑度の増大により複雑になるステークホルダ要求やＤ−Ｃａｓｅを含む生成物を分断し、それらの間の関係および制約を関係・制約データとして定義することにより、対象システムに関するディペンダビリティ要求をステークホルダが漏れなく、誤解もなく理解し、合意することができ、対象システムのディペンダビリティを、そのシステムのライフサイクル全般に亘って維持するために統御することができる。

また、本発明の実施の形態によれば、新しいシステムを既存のシステムに接続する際に、新しいシステムに関するＤ−Ｃａｓｅが対応する関係・制約データに記載の内容に合致すれば、ディペンダビリティへの影響を制御することができる。

また、本発明の実施の形態では、目的や環境の変化の際に、対象システムに関する前後の関係の把握が可能となるため、変化の前後で構造が変わりうる場合であっても、その対象システムを取り扱うことができる。

また、本発明の実施の形態におけるリポジトリ構成によれば、オープンシステムディペンダビリティを維持するために要求されるデータを、情報の構造に制約されることなく、ディペンダビリティ特性（dependability attributes）を犠牲にすることなく、永続化（persistence）することができる。

なお、上述の実施の形態は本発明を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本発明の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本発明は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。

また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、ＣＤ（Compact Disc）、ＭＤ（MiniDisc）、ＤＶＤ（Digital Versatile Disc）、メモリカード、ブルーレイディスク（Blu-ray（登録商標）Disc）等を用いることができる。

１００ ＤＥＯＳプロセス
１００−０１ 変化対応サイクル
１００−０２ 障害対応サイクル
１００−０７ 通常運用状態
１１０ 合意記述データベース
２００−０１ ルールエンジン部
２００−０２ モデル処理部
２００−０３ 永続化部
２００−０４ ハイブリッドデータベース部
２００−０５ 基本ツール部
４００−０５ ルール処理部
４００−０６ スクリプト処理部
４００−１３ 索引部
４００−１４ グラフデータベース
４００−１５ ＸＭＬデータベース
４００−１６ 文書データベース

Claims (10)

1. 対象システムのライフサイクル全般に亘って生成される複数の生成物に基づいて複数のモデルを処理するモデル処理部と、
   前記複数のモデルに基づいて前記複数の生成物の関係および制約に関する条件およびその条件に応じた処理をルールとして定義するルールエンジン部と、
   前記複数の生成物を前記複数のモデルおよび前記ルールとともに記録する永続化部と
   を具備するデータベースシステム。
2. 前記モデル処理部は、前記複数の生成物から対応する前記複数のモデルに従った構造データを抽出するとともに、対応する前記複数のモデルと他の前記複数のモデルとの間の関係データを抽出してデータベースに記録させるモデルインスタンス導入部を備える請求項１記載のデータベースシステム。
3. 前記モデル処理部は、前記複数の生成物に対応するモデルが存在しない場合に、新たなモデルを定義して前記ルールエンジン部に供給するとともに、前記新たなモデルに付随する前記ルールおよびスクリプトを前記データベースに記録させるモデル定義部を備える請求項１記載のデータベースシステム。
4. 前記モデル処理部は、前記複数のモデルにメタモデルが付随している場合に、そのメタモデルの関係および制約の条件を検証して充足処理を行うメタモデル処理部を備える請求項１記載のデータベースシステム。
5. 前記ルールエンジン部は、前記モデル処理部から供給されたモデルについてそれに付随するルールおよびそのルールに対応するスクリプトを定義する条件評価準備部を備える請求項１記載のデータベースシステム。
6. 前記ルールエンジン部は、
   前記複数のモデルに付随するルールが処理される場合には、前記生成物から抽出されたモデルに付随したルールを評価して処理対象となる前記ルールを抽出する条件評価部と、
   前記抽出されたルールに対応するスクリプトを実行するスクリプト実行部と
   を備える請求項１記載のデータベースシステム。
7. 前記ルールエンジン部は、前記条件評価部によって前記複数のルールが抽出された場合には対応するスクリプトの実行順序を決定して前記スクリプト実行部に実行させるルール順序化部をさらに備える請求項６記載のデータベースシステム。
8. 前記複数のモデルの特性に適した複数の記録処理部と、
   前記複数の記録処理部に対して索引処理を行う索引部と
   をさらに具備する請求項１記載のデータベースシステム。
9. 対象システムのライフサイクル全般に亘って生成される複数の生成物に基づいて複数のモデルを処理するモデル処理手順と、
   前記複数のモデルに基づいて前記複数の生成物の関係および制約に関する条件およびその条件に応じた処理をルールとして定義するルール定義手順と、
   前記複数の生成物を前記複数のモデルおよび前記ルールとともに記録する永続化手順と
   を具備するデータベースシステムの制御方法。
10. 前記複数のモデルの特性に適した複数の記録処理部に対して索引処理を行う索引手順をさらに具備する請求項３記載のデータベースシステムの制御方法。

Images