"対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置であって、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定手段と、を備えることを特徴とするディペンダビリティ維持装置。上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルの少なくとも何れか一方を実行することを特徴とする請求項1に記載のディペンダビリティ維持装置。上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記障害対応サイクルを実行するとともに、上記障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段を備えることを特徴とする請求項1に記載のディペンダビリティ維持装置。上記ディペンダビリティ記述データには上記再構成の手順が記載されており、上記再構成手段は、上記ディペンダビリティ記述データに記載されている再構成の上記手順に従って、当該対象システムを再構成することを特徴とする請求項3に記載のディペンダビリティ維持装置。上記障害発生または障害予兆を検知し、上記対象システムの停止が不回避であるとき、上記変化対応サイクルを実行する装置に、上記ディペンダビリティ記述データの変更の要求を送信する変更要求送信手段を備えることを特徴とする請求項3または4に記載のディペンダビリティ維持装置。上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記変化対応サイクルを実行するとともに、上記障害対応サイクルを実行する装置から、上記ディペンダビリティ記述データの変更の要求を受信したとき、上記ディペンダビリティ記述データを変更することを特徴とする請求項1に記載のディペンダビリティ維持装置。上記ディペンダビリティ記述データは、互いに関連づけられたゴールノードとモニタノードとの組を規定するデータであり、上記ゴールノードは、要求仕様がゴール形式にて記述されたノードであり、上記モニタノードは、上記ゴールノードに記述されたゴールが充足されていることを表明するエビデンスであるとともに、上記対象システムの監視点に対応付けられており、上記ディペンダビリティ値決定手段は、対応付けられた上記監視点から取得されたデータが変動許容範囲に対して良好であるモニタノードに基づいて、上記評価値を計算することを特徴とする請求項1から6のいずれか1項に記載のディペンダビリティ維持装置。上記ディペンダビリティ値決定手段は、上記対象システムをモニタして取得されたモニタ値が変動許容範囲に対して良好であったエビデンスに基づいて、上記評価値を計算することを特徴とする請求項1から6のいずれか1項に記載のディペンダビリティ維持装置。上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記障害対応サイクルを実行するとともに、上記障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに含まれるスクリプトを実行するスクリプト処理手段を備え、上記スクリプトは上記対象システムを変動許容範囲の状態に回復させるシナリオを含むことを特徴とする請求項1に記載のディペンダビリティ維持装置。対象システムのディペンダビリティを維持するためのディペンダビリティ維持システムであって、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを要求仕様の変更に合わせて変更する変化対応サイクルを実行するワークスペース装置と、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルを実行するランタイム装置とを含み、上記ワークスペース装置および上記ランタイム装置の少なくともいずれか一方が、上記ディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めることを特徴とするディペンダビリティ維持システム。他のディペンダビリティ維持システムとネットワークを介して接続されていることを特徴とする請求項10に記載のディペンダビリティ維持システム。対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置の制御方法であって、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得ステップと、上記記述データ取得ステップにて取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定ステップと、を含むことを特徴とするディペンダビリティ維持装置の制御方法。請求項1から9いずれか1項に記載のディペンダビリティ維持装置の上記各手段としてコンピュータを機能させるための制御プログラム。請求項13に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置であって、上記監視制御対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出し、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成するディペンダビリティ記述変換部を備えたことを特徴とするディペンダビリティ維持装置。上記障害監視制御部は、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行するために使用するモジュールを、複数のモジュールから選択して制御可能であり、上記ディペンダビリティ記述データは、1つの記述が、上記モジュールを特定するためのモジュール特定情報を値として設定可能な変数を少なくとも含む形式であり、上記ディペンダビリティ記述変換部は、あらかじめ設定された、上記モジュール特定情報と上記障害監視制御用データとの対応関係を示す情報に基づいて、上記ディペンダビリティ記述データに含まれる変換対象の記述を、該記述に含まれるモジュール特定情報に対応する障害監視制御用データに変換することを特徴とする請求項15に記載のディペンダビリティ維持装置。上記ディペンダビリティ記述データの1つの記述から変数部分を除いた固定部分に対応して、上記対応関係が設定されており、上記ディペンダビリティ記述変換部は、上記ディペンダビリティ記述データの記述に含まれる上記固定部分に対応する上記対応関係を参照して、該記述を対応する障害監視制御用データに変換することを特徴とする請求項16に記載のディペンダビリティ維持装置。請求項15から17のいずれか1項に記載のディペンダビリティ維持装置と、上記ディペンダビリティ記述格納部と、上記障害監視制御部とを含み、上記ディペンダビリティ維持装置が上記ディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから生成した障害監視制御用データに従って、上記障害監視制御部が動作することにより、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行することを特徴とする障害対応システム。上記監視制御対象システムの状態を監視する1以上のモニタモジュールと、必要な場合に上記監視制御対象システムに対して対策を実行する1以上のアクションモジュールと、上記障害監視制御部の制御により、上記モニタモジュールの選択および動作の制御を行うモニタ管理部と、上記障害監視制御部の制御により、上記アクションモジュールの選択および動作の制御を行うアクション管理部と、を含むことを特徴とする請求項18に記載の障害対応システム。監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置の制御方法であって、上記監視制御対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出す読み出しステップと、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成する変換ステップとを含むことを特徴とするディペンダビリティ維持装置の制御方法。請求項15から17のいずれか1項に記載のディペンダビリティ維持装置としてコンピュータを機能させるための制御プログラムであって、コンピュータを上記ディペンダビリティ記述変換部として機能させるための制御プログラム。請求項21に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。システム規模の拡大や複雑度の増大は、当該システムやそれが提供するサービスに関する要求仕様をも複雑にしている。そのため、すべての要求を完全にシステム開発前に抽出したり、全ての仕様を完全にシステム開発前に記述することが不可能仕様の不完全性になっている。仕様の不完全性は対応する実装も完全ではなく実装の不完全性、当該システムが提供するサービスの振る舞いも完全には把握することができない。その結果、何をどこまで保証したら良いのか保証可能なのかも分からない。また、これらの不完全性はステークホルダ間でのシステムやサービスに対する要求理解の違い誤解を招いたり、人為的なミスを誘導したりする。さらに、先に述べた環境の変化に対応するための要求が新たに発生する。また、開発時点の要求にも修正が必要になる。環境がどのように変化するかは事前には分かり得ないので、現在のシステムの動作が、環境変化に確実に対応できるかもわからない。このような変化に対する不確実性はシステム動作予測を困難にし、システム障害に繋がる。これらの不完全性や不確実性はシステム障害が発生した際に、その原因調査に時間がかかるようになり、またその適切な対応を困難にし、ステークホルダが自らの説明責任を果たすことも難しくなる。このような状況下において、従来、非特許文献2においては、システム開発時点で想定される障害対応をSafetyCaseとして記述し、ステークホルダ間で合意することで、障害発生時点でのステークホルダの説明責任の達成を可能にしている。しかし、環境の変化に起因するSafetyCaseの変更には対応できない。また、非特許文献3は、FaultsErrorsFailuresという変化で障害をとらえることで障害の発生そのものを抑えようとしている。しかし、前記不完全性や不確実性を扱うことはできない。また、非特許文献5には、前記不完全性や不確実性を扱うための手法に関して記載されている。しかし、その記述は実行環境とは分離されており、また、記述をモデル化しディペンダビリティの価値を計測評価することに関しては設計時のみにて可能であるに過ぎない。一方、特許文献1はEnterpriseArchitectureにおける複雑性を数学的に制御する手法に関して述べている。複雑性が制御できればディペンダビリティの向上につながることが期待できるが、前記不完全性や不確実性までは扱っていない。また、従来のシステム開発の手法では、複数のステークホルダ群からの要求は合意された仕様書にまとめられていなかったり、仕様書にまとめることが容易でないことに加えて、運用後にシステムの一部に変更があった場合に、仕様書とシステム実装の変更とを無矛盾に維持することができなかった。例えば、上記SafetyCaseでも、SafetyCaseに記載されている、ステークホルダがSafetyCase上で合意した障害対応内容と、実際の対象システムの障害対応やシステム監視制御部の開発追加などとが無矛盾であることを維持する実用的なシステムは存在していない。このようなSafetyCaseと対象システムとの無矛盾性は、ほぼ人手で行わなければならず、システムの更新と、SafetyCaseの更新を無矛盾に行うことは、時間的なずれが生じるなど、問題点が多い。一般に、SafetyCaseのような、認証機関などを含む、広範囲のステークホルダが理解可能な形式で記述されたドキュメントと、システムの実際の動作との間の無矛盾性を保証する実用的なシステムは、発明者が知る範囲においてはない。本発明は、上記の問題点に鑑みてなされたものであり、その目的は、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援することを可能にすると共に、対象システムの仕様書群と当該システムの実装を無矛盾に維持することを容易にするディペンダビリティ維持装置等を実現することにある。なお、本発明では、システムのディペンダビリティを非特許文献3などの定義に、複数のステークホルダ間での合意を含んだものに拡張する。上記課題を解決するために、本発明に係るディペンダビリティ維持装置は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置であって、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定手段と、を備えることを特徴としている。また、本発明に係るディペンダビリティ維持装置の制御方法は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置の制御方法であって、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得ステップと、上記記述データ取得ステップにて取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定ステップと、を含むことを特徴としている。上記の構成によれば、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データに基づいて、対象システムのディペンダビリティの価値を定量的に示す評価値を求めることができる。なお、上記要求仕様は、ステークホルダ群によって合意されたものであることが必要がある少なくとも、合意されたものであることが望ましい。それゆえ、対象システムのディペンダビリティの価値を定量的に表現でき、したがって、例えば、要求変更に伴ってディペンダビリティ記述データを変更するときや、対象システムの運用時に対象システムの状態を確認するときに、対象システムのディペンダビリティの価値を分かりやすく客観的に提示することができる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となるという効果を奏する。すなわち、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援することが可能となるという効果を奏する。また、本発明に係るディペンダビリティ維持システムは、対象システムのディペンダビリティを維持するためのディペンダビリティ維持システムであって、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを要求仕様の変更に合わせて変更する変化対応サイクルを実行するワークスペース装置と、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルを実行するランタイム装置とを含み、上記ワークスペース装置および上記ランタイム装置の少なくともいずれか一方が、上記ディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めることを特徴としている。なお、上記のディペンダビリティ維持装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記の各手段として動作させることにより上記ディペンダビリティ維持装置をコンピュータにて実現させるディペンダビリティ維持装置のプログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。また、本発明に係るディペンダビリティ維持装置は、監視制御対象システム以下、本発明では、対象システムが特に監視対象に係る場合には、当該対象システムを監視制御対象システムとも呼ぶの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置であって、上記監視制御対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出し、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成するディペンダビリティ記述変換部を備えたことを特徴としている。また、本発明に係るディペンダビリティ維持装置の制御方法は、監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置の制御方法であって、上記監視制御対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出す読み出しステップと、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成する変換ステップとを含むことを特徴としている。上記の構成によれば、ディペンダビリティ維持装置がディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから障害監視制御用データを生成する。そして、これに従って障害監視制御部が動作することにより、障害監視制御部が監視制御対象システムの状態を監視し、必要な場合に対策を実行することができる。ここで、ペンダビリティ記述データは、監視制御対象システムのディペンダビリティに関わる要求仕様を記述したものである。そして、監視制御対象システムの各ステークホルダが監視制御対象システムのディペンダビリティに関して合意した際、その結果がペンダビリティ記述データとして記述され、ディペンダビリティ記述格納部に格納されたものである。このように、障害監視制御部が用いる障害監視制御用データが、ディペンダビリティ記述格納部に格納されたディペンダビリティ記述データから、ディペンダビリティ維持装置によって生成されることにより、ディペンダビリティ記述データと障害監視制御部の動作とが常に無矛盾に維持されることが可能となる。また、本発明に係る障害対応システムは、上記記載のディペンダビリティ維持装置と、上記ディペンダビリティ記述格納部と、上記障害監視制御部とを含み、上記ディペンダビリティ維持装置が上記ディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから生成した障害監視制御用データに従って、上記障害監視制御部が動作することにより、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行するように構成してもよい。なお、上記のディペンダビリティ維持装置および障害対応システムは、コンピュータによって実現してもよく、この場合には、コンピュータを上記ディペンダビリティ記述変換部として動作させることにより上記ディペンダビリティ維持装置をコンピュータにて実現させるディペンダビリティ維持装置のプログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。以上のように、本発明に係るディペンダビリティ維持装置は、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定手段と、を備える構成である。また、本発明に係るディペンダビリティ維持装置の制御方法は、対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得ステップと、上記記述データ取得ステップにて取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定ステップと、を含む方法である。それゆえ、対象システムのディペンダビリティの価値を定量的に表現できる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となるという効果を奏する。すなわち、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援することが可能となるという効果を奏する。また、本発明に係るディペンダビリティ維持装置は、監視制御対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出し、読み出したディペンダビリティ記述データから障害監視制御用データを生成するディペンダビリティ記述変換部を備えた構成である。また、本発明に係るディペンダビリティ維持装置の制御方法は、監視制御対象システムのディペンダビリティに関する要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出す読み出しステップと、読み出したディペンダビリティ記述データから障害監視制御用データを生成する変換ステップとを含む方法である。それゆえ、障害監視制御部が用いる障害監視制御用データが、ディペンダビリティ記述格納部に格納されたディペンダビリティ記述データから、ディペンダビリティ維持装置によって生成されることにより、ディペンダビリティ記述データと障害監視制御部の動作とが常に無矛盾になるように維持することが可能となるという効果を奏する。本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分に分かるであろう。また、本発明の利点は、添付図面を参照した次の説明で明白になるであろう。実施の形態1本実施の形態に係るワークスペースコンピュータ101および/またはランタイムコンピュータ102は、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援するものである。そのため、後述するように、本実施の形態に係るワークスペースコンピュータ101および/またはランタイムコンピュータ102は、対象システムのディペンダビリティに関する仕様を記述したディペンダビリティ記述データ時間軸上でモデルの変化を可能にした上で対象システムの構造を計算可能なモデルとして表現することを可能にする差分構造モデルで記述されるデータであってもよい。に基づいて、対象システムのディペンダビリティの価値を定量的に示すD値を求める。以下、図1から図41に基づいて、本発明の一実施の形態について詳細に説明する。1.ハードウェア構成図1は、本実施の形態に係るディペンダビリティ維持システム100の構成の概略を示す機能ブロック図である。図1に示すように、ディペンダビリティ維持システム100は、ディペンダビリティ維持装置としてのワークスペースWorkspaceコンピュータディペンダビリティ維持装置、ワークスペース装置101およびランタイムRuntimeコンピュータディペンダビリティ維持装置、ランタイム装置102を含んで構成され、それらはネットワーク103で接続される。ワークスペースコンピュータ101で処理されたソフトウェアSWは、ランタイムコンピュータ102に展開されて処理される。また、対象システム、あるいはアプリケーションシステムとその実行に必要なライブラリ、ミドルウェア、システムサービス等のサポートシステムはランタイムコンピュータ102に含まれる。ソフトウェアSWは、バイナリ実行部110110W、110R;ワークスペースコンピュータ101のバイナリ実行部110Wとランタイムコンピュータ102のバイナリ実行部110Rを区別する場合は、W,Rを付して記す。で処理可能な表現形式を有している。ソフトウェアSWは対象システムで稼働するアプリケーションとその実行に必要なライブラリ、ミドルウェア、システムサービス等の実行環境を含む。ワークスペースコンピュータ101は、検証ツール部101-01、編集ツール部101-02、解析ツール部101-03、開発ツール部101-04、合意形成支援ツール部101-05、バイナリ実行部110Wを備えて構成される。なお、機能ブロックは必ずしもこれらに限定されるものではないが、これら代表的な機能について簡単に説明する。検証ツール部101-01は、ソフトウェアSWを検証する。編集ツール部101-02は、ソフトウェアSWを編集する。解析ツール部101-03は、ソフトウェアSWを解析する。その際、ランタイムコンピュータ102からの情報を用いても良い。開発ツール部101-04は、ソフトウェアSWを開発するために利用される。また、ランタイムコンピュータ102は、更新部102-01、記録部102-02、モニタリング部102-03、再構成部再構成手段102-04、隔離部102-05、スクリプト処理部スクリプト処理手段102-07、バイナリ実行部110Rを備えて構成される。なお、機能ブロックは必ずしもこれらに限定されるものではないが、これら代表的な機能について簡単に説明する。更新部102-01は、ランタイムコンピュータ102で処理されているソフトウェアSWを更新する。記録部102-02は、ランタイムコンピュータ102の内部の状態を記録する。記録に当たっては、ソフトウェアSWの指示に従っても良いし、あらかじめ決められた所定の設定に従って記録しても良い。モニタリング部102-03は、ランタイムコンピュータ102の内部の状態を取り出すと同時に、後述するD値を算出する。状態の取得は、ソフトウェアSWの指示に従っても良いし、あらかじめ決められた所定の設定に従って取得しても良い。再構成部102-04は、ランタイムコンピュータ102の内部の構成を変更する。構成の変更に当たっては、ソフトウェアSWの指示に従っても良いし、あらかじめ決められた所定の設定に従って変更しても良いし、スクリプトの指示に従っても良い。隔離部102-05は、ランタイムコンピュータ102の内部の一部の構成を切り離して独立させる。スクリプト処理部102-07は、後述のディペンダビリティ記述データから導出されるスクリプトを実行する。ここで、ディペンダビリティ維持システム100は、図1に示すように、別個の二台のコンピュータで構成されるシステムであっても良いし、1台のコンピュータで構成されるシステムであっても良いし、各々が2台あるいはそれ以上の台数のコンピュータから構成されるシステムであっても良い。2台あるいはそれ以上で構成されるときには、各コンピュータはネットワーク103で接続されていればよい。図2に、ワークスペースコンピュータ101およびランタイムコンピュータ102のハードウェア構成を示す。もっとも基本的な構成としては、ワークスペースコンピュータ101およびランタイムコンピュータ102は、命令バスとデータバスで接続された演算装置151と、制御装置152と、メモリ装置153と、入出力装置154とを備えた電子計算機である。入出力装置154から入力されたビットデータの情報に基づき、演算装置151において、算術演算、論理演算、比較演算、シフト演算、等が実行される。実行されたデータは必要に応じて、メモリ装置153に記憶され、入出力装置154から出力される。これら一連の処理は、メモリ装置153に記憶されたソフトウェアプログラムに従って、制御装置152によって制御される。本実施の形態におけるワークスペースコンピュータ101およびランタイムコンピュータ102は、上記のコンピュータとしての基本機能を備えたハードウェアであり、オペレーティングシステムやデバイスドライバ、ミドルウェア、アプリケーションソフトウェアといったプログラム群によって制御されている。図3に本実施の形態に係わるソフトウェアSWの構成例を示す。版管理情報104-01は、当該ソフトウェアSWに関する版管理に関する情報であり、タイムスタンプを含んでいても良い。ディペンダビリティ記述データ104-02は、当該ソフトウェアSWに関する後述のディペンダビリティ記述データに関する情報である。バイナリコード104-03は、当該ソフトウェアSWの処理をバイナリ実行部110が解釈実行可能な表現形式で記述した情報である。外部参照情報104-04は、当該ソフトウェアSWが必要とする、あるいは依存している外部のソフトウェアに関しての情報である。2.ディペンダビリティ記述データ図4は、一例としてのアプリケーションを示す説明図である。ここでは、WEBアプリケーションを例に説明する。図4aは、当該アプリケーションが3層構造モデルを成していることを示している。プレゼンテーション層Presentation200-01は、当該アプリケーションの表示及び入力を担当する。データアクセス層Dataaccess200-03は、当該アプリケーションが実行を進めるに当たって必要となるデータを格納し管理する。アプリケーションロジック層Applicationlogic200-02は、ユーザからの入力の基づき当該アプリケーションとしての必要な計算処理を実行し、結果をデータアクセス層200-02に渡す。あるいは、当該アプリケーションが必要なデータをデータアクセス層200-02から入手し、処理をしてからプレゼンテーション層200-01に渡して利用者に提示する。図4bは、上記3層構造モデルを実装する際の一構成例を示している。WEBServer201-02が、上記プレゼンテーション層200-01に相当する。Client201-01は、当該アプリケーションの利用者であり、ネットワーク201-05経由で、WEBServer201-02を利用する。Client201-01、ネットワーク201-05、及びWEBServer201-02を含めてプレゼンテーション層200-01に相当すると考えても良い。AppLogic201-03は、上記アプリケーションロジック層200-02に相当する。AppLogic201-03は、WEBServer201-02とは通信路201-06を介して情報の交換を行い、DBS201-04とは通信路201-07を介して情報の交換を行う。DBS201-04は、データベースであり、AppLogic201-03の処理した、又は処理に必要なデータの格納、獲得、等の管理を行う。WEBServer201-02、AppLogic201-03、及びDBS201-04は、ランタイムコンピュータ102で実行されるが、それらが1台のコンピュータ上で実行されても、それぞれ1台ずつのコンピュータ上で実行されても良い。図5は、上記アプリケーションのディペンダビリティ記述データの一例であり、サービス継続の観点からディペンダビリティ記述データを記述している。ディペンダビリティ記述データとは、アプリケーションのディペンダビリティに関するステークホルダ間の合意された要求を記述したモデルである。以下に、図5に記載の一例の内容を説明する。WEBサービスの継続202-01は上記アプリケーションのディペンダビリティに関するゴールであり、WEBサービスが継続できることを意味している。このゴール202-01を実現するためには、当該ディペンダビリティ記述データでは、Clientの動作継続202-02、WEBServerの動作継続202-03、AppLogicの動作継続202-04、DBSの動作継続202-05の4つの特性が満足される必要がある。それぞれ、図4bのclient201-001、WEBServer201-02、AppLogic201-03、及びDBS201-04に対応している。これら4つの特性は、さらにブレークダウンされ次のように記述される。Clientの動作継続202-02のためには、デバイスの適切な動作202-06とWEBServerの適切な反応202-10という2つの特性の充足が必要である。WEBServerの動作継続202-03のためには、リクエストの適切な送受信202-07とAppLogicの適切な反応202-11の2つの特性の充足が必要である。AppLogicの動作継続202-04のためには、正常な業務処理202-08とDBSの適切な反応202-12の2つの特性の充足が必要である。DBSの動作継続202-05のためには、DBの一貫性202-09とデータの有効性202-13の2つの特性の充足が必要である。上記複数の特性の充足は、図5では、楕円形ノードに示された各種の検証を始めとする、実行時のモニタリング結果によって、把握、判断することができる。例えば、デバイスの適切な動作202-06は包括的なテストによるデバイス検査の合否202-20によって当該特性が充足されていると判断できる。WEBServerの適切な反応202-10やリクエストの適切な送受信202-07は当該サーバへのアクセスベンチマークを始めとする、実行時のログ検証による反応検査の合否202-21や遅延検査の合否202-22によって当該特性が充足されていると判断できる。AppLogicの適切な反応202-11や正常な業務処理202-08も同様に包括的なテストによるテストケース合否202-23と202-24によって当該特性が充足されていると判断できる。DBSの適切な反応202-12、DBの一貫性202-09、及びデータの有効性202-13の特性もベンチマーク、ストレステスト過負荷試験、アノマリーテスト耐異常試験による、あるいは実行時のデータベースアクセスログの検証による各々ベンチマーク合否202-25、ストレステスト合否202-26、アノマリーテスト合否202-27によって当該特性が充足されていると判断できる。本実施の形態では、これら楕円形ノードに記述された検証を、対応ノードの特性が充足していることを示す根拠エビデンスとして扱う。なお、これらのエビデンスは、後述するモニタノードによる計測値も利用される。図6は、図5がシステムの正常系に関してのディペンダビリティ記述データであったのに対し、リスクを考慮したシナリオベースのディペンダビリティ記述データの例である。すなわち、が発生したら、の対応が取れるかというシナリオを考えることで、ディペンダビリティ記述データを記述している。例えば、図6の例では、ノードのトップはDBのHDDの容量が限界データベースシステムを構成するハードディスク容量に空きがなくなったらどのような対応が取れるか203-01という、リスクが記述されている。このリスクが実際に発現しないための、4つの対策を次レベルのノードに記述している。HDD容量の拡張203-02はハードディスクの追加やより容量の大きなディスクドライブへの置き換え等の手段によって容量が拡張可能であることを記述している。バックアップDBSによる継続203-03はデータベースシステムにバックアップ系が用意されており、それを用いてデータベース機能が継続可能であることを記述している。キャッシュによるAppLogicの継続203-04はデータベースが利用できない状況でも一部キャッシュされたデータを用いてアプリケーションが継続可能であることを記述している。丁寧なエラーを利用者に返す203-05はアプリケーションの実行を続けられなくなっても何らかの説明を利用者に通知可能であることを記述している。それらのノード203-02~203-05は、その可能性を裏付ける機能をそれらのサブノードで記述している。例えば、HDD容量の拡張203-02はHDDデバイス活線挿抜ホットスワップ、すなわち停止させることなくディスクドライブを交換できること203-06機能、あるいは論理ボリュームのOSサポートボリューム容量はディスクドライブの容量に制限されないシステム機能203-07機能によって実現可能になる。バックアップDBSによる継続203-03はスタンバイ機再起動データベースシステムを複数用意しておき1つの系統が停止したときに待機していたシステムを起動させて機能を引き継ぐ203-08機能、あるいは2重系の片方のみでの継続2系統のデータベースシステムで実現した機能をその1系統が停止しても継続できる203-09機能によって実現可能になる。キャッシュによるAppLogicの継続203-04はDBへの変更の遅延書き込みデータベースへのアクセスをそれが復旧するまで遅らせる203-10機能、あるいはデータのタイムスタンプタイムスタンプを参照することで古いデータでもAppLogicを継続できる203-11機能によって実現可能になる。最後の丁寧なエラーを利用者に返す203-05はネットワークが到達可能利用者までのネットワーク通信が可能203-12によって実現可能になる。なお、これらエッジノード203-06~203-12は、図5における楕円形ノードエビデンスによってそれらの特性の充足が記述されるが、図6では省略している。上記図5に記載のディペンダビリティ記述データと図6に記載のディペンダビリティ記載データは、どちらかをステークホルダ間で合意されたディペンダビリティ記述データとして用いても良い。また、より上位のスコープのディペンダビリティ記述データの一部として、図5は正常系、図6はリスク系として、共にステークホルダ間で合意されたディペンダビリティ記述データとして用いても良い。図7は、ステークホルダ要求変更に伴って変化したディペンダビリティ記述データと、図6に示したディペンダビリティ記述データとの差分を示すディペンダビリティ記述データの記述例を示す説明図である。図6では、HDD容量の拡張203-02の可能性が当該アプリケーションの継続には重要であった。これに対して、図7では、何らかの環境の変化、例えば、ビジネスの好転によって、ステークホルダがデータベースシステムへの投資額を増やし強化する決定をした場合における、図6とは異なった時刻におけるディペンダビリティ記述データを記述している。すなわち、図6のバックアップDBSによる継続203-03の代わりに、多重系によるDBSの無停止204-01機能を採用することを決定した場合を記述している。データベースが無停止であることによって、図6のキャッシュによるAppLogicの継続203-04は不要になっている。その結果、図7の網かけされたノードが図6との差分となる。図5から図7に示したディペンダビリティ記述データは、SafetyCase表現非特許文献2を用いて記述しても良いし、図8、図9に示すように、DCase表現を用いて記述しても良い。ここで、図8を用いて、DCase表現の基本構造を説明する。対象システムのディペンダビリティに関するステークホルダ群からの要求をトップゴール210-01として記述する。トップゴールとは、対象システムに対してステークホルダ間で合意すべき命題を表す。例えば、対象システムは機能安全規格IEC61508で定義されているSafetyIntegrityLevel3を満たすなどである。当該トップゴールが満たされていることを木構造により詳細化していき、詳細化されたサブゴール210-05に対しても同様に木構造により詳細化していく。サブゴールとは、トップゴールを示すために、示すべき事を分割した命題を表す。サブゴールは、さらに小さなサブゴールに分割される。本実施の形態では、トップゴール及びサブゴールを総称してゴールと呼ぶ。当該詳細化の過程は議論の構造210-02と呼ばれる。当該ゴールをサブゴールに分割する際に、当該分割の補助説明理由理屈を示すストラテジを記述しても良い。例えば、図5に記載のディペンダビリティ記述データの一部をDCase記述で表現すると図9になる。ゴールがWEBサービスの継続202-01であり、当該ゴールにリンクしている4項目であるClientの動作継続202-02、WEBServerの動作継続202-03、AppLogicの動作継続202-04、DBSの動作継続202-05は各々サブゴールであり、それら4項目をサブゴールとする理由がストラテジサブシステムの継続性の観点で分割211-01である。また、ゴールあるいはストラテジにはコンテキストがリンクしても良い。コンテキストはゴールやストラテジの内容を補足する情報である。例えば、図9では、ゴール202-01に対してコンテキストとして当該ゴールWEBサービスの継続において継続に関しての補足説明であるサービスが停止する場合でも1分以内で回復することが付与されている。ゴールには、それが妥当であることを表明しているエビデンス210-03、210-04が存在する。エビデンスは分割され詳細化されたゴールを最終的に保証する。エビデンスの妥当性はステークホルダ間の合意に基づく。エビデンスの存在してないゴールは何らかの問題を内在している。また、図5から図9では、ディペンダビリティ記述データを木構造で表現した。しかし、ノード間の依存関係を表現し一般的なグラフ構造で表現しても良いし、あるいは表形式で表現しても良い。以下、本実施の形態では、ディペンダビリティ記述データとして前記DCase表現を用いて説明する。本実施の形態では、ディペンダビリティ記述データから計算されるD値を用いてディペンダビリティの価値を計測、評価する。D値の計算は、ワークスペースコンピュータ101においては、検証ツール部101-01のD値計算部ディペンダビリティ値決定手段101-05が、ランタイムコンピュータ102においては、モニタリング部102-03のD値計算部ディペンダビリティ値決定手段102-06が行う。D値は、ワークスペースコンピュータ101においては、例えば、ディペンダビリティ記述データの検証のために用いられ、ディペンダビリティ記述データが変更される度に計算される。また、ランタイムコンピュータ102においては、例えば、ディペンダビリティ記述データに従って動作する対象システムの監視のために用いられ、対象システムの動作中はリアルタイムに計算される。図10にディペンダビリティ記述データが表現するシステムのディペンダビリティの価値を計測、評価する手法を示す。ディペンダビリティ維持システム100にはディペンダビリティ記述データが複数存在する。トップノードは特定の特性に対するディペンダビリティの価値と定義できる。例えば、図5のWEBサービスの継続202-01は失われると困るものであり資産assetと考えられるので、本実施の形態ではディペンダビリティの価値と定義し、D値評価値と呼ぶことにする。トップノードは複数のサブノードに分解されるので、各エッジリンクを要素とする多次元ベクトルが構成できる図10a。その際に、エッジに重みを付けても良い。図5を例にするなら、例えば、ノード202-05をノード202-04よりも重要である場合、202-01と202-05のエッジの重みを、202-01と202-04のエッジより大きくしても良い。また、あるノードのサブノードの数を重みとしても良い。サブノードが多いと言うことは十分に対策が検討されていることにもなるからである。このように重み付けされたエッジの多次元ベクトル値をD値とすることができる。次元数が多くなると多次元ベクトルは扱いにくいので、主成分分析法やフィッシャー判別分析法等を用いて次元削減を行っても良い。また、設計時におけるエビデンスを教師データとして学習し、後述のモニタノードによる変化を、例えばマハラノビス距離計算によって外れ値として検出することで異常の発生検知に用いても良い。こうすることで、グラフ構造にエッジの重要性を加味した評価値が得られる。ここで得られるD値は多次元ベクトル値であるが、目的に応じた任意の変換手法によりスカラー値に変換できることはいうまでもない。また、図10bは、当該特性において、有効エビデンス/総エビデンスをD値とした例である。図5では総エビデンス数は8であるが、例えば、その中で有効数が4であるときにはD値は4/8=05となる。また、図10cは、モニタノード群におけるモニタノードでの監視点が取得したデータが変動許容範囲内であるノードと当該変動許容範囲外のノードとを色分けし、当該グラフ構造そのものをD値とする例である。なお、詳細については後述する。こうすることで、エビデンスの状態に応じた評価値が得られる。エビデンスは要求変更に応じて変化するため、ここで得られるD値も要求変更に応じて変化する。すなわち、D値を確認することで、要求変更がディペンダビリティに与える影響を評価することができる。また、非特許文献5の手法を用いても良い。当該文献ではDCase記述を図11に記載の項目で再構成している。図11に示すように、フェーズ、目的、ターゲット、異常の種類の4層にDCaseノードを再配置することで、エッジの重みを各層で一貫性のある値として扱うことが可能になり、D値を各層で比較することも可能になる。ここで、システムに求められるディペンダビリティ要件は、そのシステムの目的により異なる。また、システムのライフサイクルの各フェーズで、ステークホルダ間の合意のための作業を円滑化する必要があるが、そのためには、ディペンダビリティ要件やその実現度合いを定量的に表現する必要がある。そこで、上記のように、D値としてディペンダビリティを定量的に表現することにより、議論するための指標ディペンダビリティメトリクスが実現できる。上記のように、D値を用いることで、システム開発者は、そのシステムにおける特定のディペンダビリティ支援に関する重みを考慮して、要求そのもの、あるいは要求の実現度合いを定量化できる。また、システムの運用時には、そのシステムに不具合が発生した場合、その時点で満足し得るディペンダビリティをリアルタイムに定量化することができる。すなわち、ベンチマークや検証により得られるエビデンスとD値とを組み合わせて、ディペンダビリティ記述データを評価することが可能となる。また、動作中システムからリアルタイムにD値を得て、システムの状況を判断することが可能となる。ここで、図12を用いて、ランタイムコンピュータ102における、モニタリング部102-03のD値計算部102-06の一実施例を説明する。D値を当該ランタイムコンピュータ102においてステークホルダ合意に基づいて実行時に計算するために、図8に記載のDCaseに対象システム内部のどの機能を、いつ、どのように監視するかをステークホルダ間での合意の上で記述するDCaseモニタノードを導入する図12。DCase記述におけるゴールを表現するノードには、当該ゴールが満足しているエビデンスを表明するノードを関連付けることができる。この際のエビデンスに相当するノードに対象システム内部の監視点からのデータを収集し、当該データが変動許容範囲にあるかどうかを判断させるように構成できる。変動許容範囲とは、監視点から得られたデータが基準値であるか、基準値に準じているかの範囲を示している。例えば、ネットワーク帯域の場合には、1Mbps~2Mbpsの範囲にあれば通常の動作であると見なすことができる範囲と定義できる。アプリケーションのメモリ消費であれば、100MB以内の消費であれば通常の動作であると見なすことができる範囲と定義できる。なお、当該変動許容範囲はステークホルダ合意に基づいて設定されている。図12において、ゴール220-01に対してはモニタノード220-03が、ゴール220-02に対してはモニタノード220-04が、それぞれリンクしている。モニタノード220-04は実行環境220-07における監視点1220-05からのデータを取得し、当該データが変動許容範囲にあるときにはゴール220-02を満足していることを意味している。また、モニタノード220-03は実行環境220-07における監視点2220-06からのデータを取得し、当該データが変動許容範囲にあるときにはゴール220-03が満足していることを意味している。ここで、監視点1220-05の取得するデータはアプリケーション220-10内部の監視対象センサ220-08からデータを取得している。当該センサには、例えば、当該アプリケーションの消費しているメモリ量であったり、当該アプリケーションが外部と通信している遅延や帯域幅であったりする。一方、監視点2220-06の取得するデータはアプリケーション220-10内部の開始対象ログ220-09から取得している。一般に、ログから対象システムの監視対象が変動許容範囲内にあることを判断するには、ログ内部を精査する必要がある。そこで、本実施例では一例として、スクリプトを導入し、ログを精査して監視点対象が変動許容範囲にあることを判断するように構成する。なお、当該スクリプトもステークホルダ合意に基づいている。本発明の一実施例として、ステークホルダによる当該合意を電子署名によって表現し、実行時に確認するように構成しても良い。図13にその一例を示す。図12におけるDCase記述の概略は図13のように描けるが、ここでは3つの電子署名の有効範囲を示している。範囲211-01は全体に対する電子署名であり、範囲221-02は1組のゴールとモニタノードに対する電子署名であり、範囲221-03は1組のゴールとモニタノードとスクリプトに対する電子署名である。前記電子署名は、その有効期限を定めるように構成可能である。例えば、開発時にのみ有効な電子署名をDCase記述に付与したり、状況に依存した期間で有効な電子署名をDCase記述に付与しても良い。これにより、モニタノードによるデータ取得の信頼性を高め、エビデンスとしての利用をより確実にできる。また、電子署名のあるDCase記述と電子署名のないDCase記述とが混在する環境においては、電子署名のないDCase記述を処理する場合にはデフォルトの動作を決めておくように構成できる。一般的にデフォルトの動作は、電子署名が無効である場合と同様の拒絶の処理をすべきである。しかし、状況によってはオペレータやユーザに確認を求めるように構成しても良い。前記DCaseモニタノードにて取得されるデータをD値計算に用いても良い。図10cに一例を示す。本実施例ではDCase記述はモジュール毎に存在するように構成できる。当該DCase記述そのものは木構造であり、その一部であるDCaseモニタノードも木構造を構成するが、対象システム全体のDCaseモニタノードの構造は図10cのような一般化されたグラフ構造を用いて構成できる。ここでは、ノード間の距離を評価するように構成しても良い。ノード群同士の直接リンクをノード間に複数のリンクがある構造よりも評価値を大きくできる。また、当該モニタノード群におけるモニタノードでの監視点が取得したデータが変動許容範囲内であるノードと当該変動許容範囲外のノードとを色分けし、当該グラフ構造そのものをD値として構成しても良い。当該色分けに際して、変動許容範囲に深刻度Sevirityを定義しても良い。例えば、ハードディスクの残容量に関する変動許容範囲の場合には、残容量50と残容量10とは異なった深刻度を与えた方が望ましい。当該グラフ構造にはモジュール間の依存関係を反映しているので、グラフ構造をD値とすることは、当該依存関係を考慮したD値をディペンダビリティの価値として扱うことができる。さらに、図14示すように、エッジのゴール群220-04乃至222-07以外に、途中のゴール群222-01乃至222-03に前記モニタノードをリンクしても良い223-01乃至223-03。あるゴールにリンクされたモニターノードと当該ゴールのサブノード群にリンクされたモニタノード群との関係は、対応する監視点群の関係に相当する。例えば、ゴール2222-02が商品購入サイトのサービス継続である場合、そのサブゴールを2個に分割し、ゴール4222-04が電子決済システムの継続であり、ゴール5222-05が商品DBの継続であるように構成できる。当該ゴール群に対して、各々次のモニタノードをリンクする。モニタノード2223-02はゴール2222-02にリンクされ、例えば、スクリプトによって包括的なサービス継続シナリオを実行することで、当該ゴール2が満足していることを確認する。モニタノード4223-04はゴール4222-04にリンクされ、例えば、スクリプトによって電子決済システムに異常が無いことを確認し当該ゴール4が満足していることを確認する。モニタノード5223-05はゴール5222-05にリンクされ、例えば、商品DBに具備された死活センサからデータを受領することで当該ゴール5が満足していることを確認する。また、次のように構成しても良い。例えば、ゴール3222-03が商品候補表示システムの継続である場合、そのサブゴールを2個に分割し、ゴール5222-05が規定値アクセス数以下での正常動作であり、ゴール6222-06が規定値遅延以内での正常動作であるように構成しても良い。当該ゴール群に対して、各々次のモニタノードをリンクする。モニタノード6223-06はゴール6222-06にリンクされ、例えば、スクリプトによって規定値アクセス数以下で正常に動作していることを確認することで、当該ゴール6が満足していることを確認する。モニタノード7223-07はゴール7222-07にリンクされ、例えば、対象システムのWEBサーバに組み込まれたセンサのデータを取得して規定値以下の遅延で正常に動作していることを確認することでゴール7が満足していることを確認する。この場合には、ゴール3222-03にリンクされたモニタノード3223-03は、サブゴールである当該ゴール6と当該ゴール7が共に満足していることを確認することで、当該ゴール3が満足されていることを確認したこととするように構成できる。以上のように、モニタノード群をグラフ構造によって構成することで、上記D値をグラフ構造を計算することで取得し、システムの状況を判断することができる。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、不完全性と不確実性が潜在的に存在するオープン環境におけるシステム開発及びシステム運用、さらにシステムが提供するサービスにおけるディペンダビリティを持続的に維持する目的で、かつ、ステークホルダ間における要求の誤解、環境の変化に対する対応不能、障害対応の失敗という3つの問題に対応する目的で、ディペンダビリティに関して時間軸上で変化可能なある時刻におけるディペンダビリティ記述データデータ構造としては、例えば、木構造モデルを備えるシステムにおいて、当該ディペンダビリティ記述データを計算することができ、それによって当該ディペンダビリティ記述データが表現するシステムのディペンダビリティの価値を計測、評価するものであってもよい。このように、前記ディペンダビリティ維持装置は、ディペンダビリティに関して時間軸上で変化可能なある時刻におけるディペンダビリティ記述データを備えるシステムにおいて、ディペンダビリティの価値を計測、評価することができる。したがって、ステークホルダ間における要求の誤解、環境の変化に対する対応不能、障害対応の失敗という3つの問題に対処することでディペンダビリティを維持することが可能となるという効果を奏する。また、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置であって、対象システムのディペンダビリティに関する仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段ディペンダビリティ記述データ入力部901-01、ソフトウェア入力部902-01と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値D値を求めるディペンダビリティ値決定手段D値計算部101-05、D値計算部102-06と、を備えて構成されても良い。これにより、対象システムのディペンダビリティの価値が定量的に表現できる。したがって、例えば、要求変更に伴ってディペンダビリティ記述データを変更するときや、対象システムの運用時に対象システムの状態を確認するときに、対象システムのディペンダビリティの価値を分かりやすく客観的に提示することができる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となる。さらに、本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、上記ディペンダビリティ記述データがノード間のエッジに重み付けが可能な木構造あるいはグラフ構造を有するデータであり、上記ディペンダビリティ値決定手段D値計算部101-05、D値計算部102-06は、上記エッジに重み付けされた重みを要素とする多次元ベクトル値を上記評価値D値とするように構成されても良い。これにより、木構造あるいはグラフ構造に、エッジの重要性を加味した評価値が得られる。よって、評価値を確認することで、エッジに重み付けの変更がディペンダビリティに与える影響を評価することができる。なお、ここで得られる評価値は多次元ベクトル値であるが、目的に応じた任意の変換手法によりスカラー値に変換できることはいうまでもない。さらに、本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、上記ディペンダビリティ値決定手段D値計算部101-05、D値計算部102-06は、上記ディペンダビリティ記述データに含まれるエビデンスの総数である総エビデンス数に対する、上記対象システムをモニタして取得されたモニタ値が変動許容範囲に対して良好であったエビデンスの数である有効エビデンス数の割合を上記評価値D値として計算するように構成されても良い。これにより、エビデンスの状態に応じた評価値が得られる。エビデンスは要求変更に応じて変化するため、ここで得られる評価値も要求変更に応じて変化する。すなわち、評価値を確認することで、要求変更がディペンダビリティに与える影響を評価することができる。さらに、本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、上記ディペンダビリティ記述データをグラフ構造として評価し、上記ディペンダビリティ値決定手段D値計算部101-05、D値計算部102-06は、当該グラフ構造を計算して、例えばノード間距離や深刻度を計算式に組み込み評価値D値を算出しても良い。これにより、モニタノード群により得られるデータに応じた評価値が得られる。モニタノード群は対象システムの実行時の状況に応じて変化するため、ここで得られる評価値も当該実行状況に応じて変化する。すなわち、当該評価値を確認することで、実行状況がディペンダビリティに与える影響を評価することができる。また、本発明のディペンダビリティ維持システム100は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持システムであって、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300を実行するワークスペース装置ワークスペースコンピュータ101と、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301を実行するランタイム装置ランタイムコンピュータ102とを含み、上記ワークスペース装置および上記ランタイム装置の少なくともいずれか一方が、上記ディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値D値を求めるように構成されても良い。さらに、本発明のディペンダビリティ維持システム100は、他のディペンダビリティ維持システム100とネットワークを介して接続されていても良い。すなわち、本発明のディペンダビリティ維持システム100は、複数、ネットワークを介して接続されていても良い。3.二つのプロセス図15を用いて、ディペンダビリティ維持システム100が有する反復的プロセスに関して、また、図16を用いて、当該反復的プロセスを実現するためのアーキテクチャに関して説明する。オープンシステムディペンダビリティ、すなわち、機能、構造、システム境界が時間とともに変化し続けるシステムに対するディペンダビリティの実現の為には、反復的プロセスとしてのアプローチが必須である。当該反復的プロセスは、目的Objectivesや環境の変化に対してシステムを継続的に変更していくためのサイクル変化対応サイクルP300と、障害に対して迅速に対応するためのサイクル障害対応サイクルP301を備えている必要がある。当該反復的プロセスは、構成要素として要求マネジメントプロセス250-01、開発プロセス250-02、通常運用プロセスS302、障害対応サイクル250-04、説明責任遂行プロセス250-05等を含むプロセスのプロセスProcessofProcessesである。当該構成要素プロセスは相互に有機的に結びつけられる必要がある。本実施の形態では当該反復プロセスをDEOSプロセスと呼ぶ。対象システムのディペンダビリティに関する利害関係者をDEOSプロセスにおいてはステークホルダと呼ぶ。ステークホルダとしては、以下を想定している。1サービス製品の利用者顧客、社会的インフラの場合は社会全体、2サービス製品の提供者事業主、3システム提供者設計開発者、保守運用者、ハードウェア供給者、4サービス製品認可者規制監督官庁。ステークホルダは時間の経過や環境の変化によってそれぞれの目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化をここでは目的環境変化と呼ぶこととする。これらの変化に対し、当該ステークホルダは熟慮し、相互に合意したうえで、適切な時期にシステムの変更を要求する。DEOSプロセスはこのような要求に対するサイクルとして、変化対応サイクルP300を備える。対象システムは不完全さと不確実さに起因する障害を完全に回避することがきわめて困難である。障害の予兆を検出した場合には障害を未然に回避し、不幸にも障害が発生してしまった場合には迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。DEOSプロセスではそのような状況に対応するために障害対応サイクルP301を備える。新規にシステムを開発し、また、目的環境の変化に対応してシステムの変更を行う場合、その理由やステークホルダ間で行われた議論の過程、合意内容などを詳細に記録するための合意記述データベース250-06を備えていることが効果的な前記反復的プロセスを実現し、説明責任を遂行するために必須である。当該データベースにはディペンダビリティを達成するための議論や根拠を記述した前記DCase、障害に対してサービスを継続するためのシナリオを基に障害予兆の検出や障害発生に迅速に対応するための実行手続きを記述したスクリプト詳しくは後述するが図中ではDScriptとして記載が含まれている。そして、これらの合意記述を基に開発プロセス250-02、障害対応サイクル250-04、通常運用プロセスS302が実行され、また、説明責任遂行プロセス50-05を支援することができる。合意記述データベース250-06は前記構成要素プロセスを有機的に繋ぐ重要な役割を果たす。前記DEOSプロセスの特徴をまとめる。1通常運用S302から開始される変化対応サイクルP300と障害対応サイクルP301の2つのサイクルから成り立っていること。2システム変更要求のためのステークホルダ合意250-07と、システム変更や障害対応の説明責任遂行250-05の2つのフェーズが組み入れられていること。3ステークホルダ間で利害関係を調整し、ディペンダビリティを達成するために議論した過程、論拠、結果等を記述した前記DCaseと障害に迅速に対応するための実行手続きを記述したスクリプトを含む合意記述データベース250-06を備え、構成要素プロセスを有機的に結合すること。図15において通常運用S302はディペンダビリティ維持システム100が通常運用状態にあることを示している。当該通常運用S302はシステムがステークホルダ間で合意されたサービスレベル変動許容範囲InOperationRangeから大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクルP300は通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクルP301も通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、当該スクリプトに記されたサービス機能レベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。あるいは一部の機能を縮退してサービスを継続している場合もある。しかしながらサービスの提供が完全に停止されてしまう場合もある。通常運用状態S302において実行されるプロセスには、日常的な動作記録の点検、プロセスの定期的な見直し改善、要員の訓練しつけ教育など、継続的なディペンダビリティ向上活動が含まれる。システムの稼働状況を記録し、日々点検する事により保守担当者や運用担当者が、何かの兆候をそこから見出す事ができる可能性がある。また、システムのメモリー資源を常にクリーンな状態にすることも、非常に有効な日常保守改善活動である。あるいは、積極的に予行を行うことも有効である。障害はある時間が経過してある状態に達した時発生する。であれば、時間を先に経過させると障害の発生を事前に知ることができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかはその時の状況による。障害対応サイクルP301に関して概説する。障害対応サイクルP301は障害に対して迅速に対応して障害による被害を最小化するためのサイクルである。DEOSプロセスでは障害をステークホルダ間で合意されたサービス機能レベル変動許容範囲から逸脱する事象と定義する。障害対応サイクルにおける主要なフェーズは、未然回避250-10、迅速対応250-09、原因究明250-08であり、障害が発生した場合は説明責任遂行が必須である。当該3フェーズはそれぞれ別個に、かつ順番に行われるとは限らない。多くの場合、これらはお互いが関連しあい、渾然一体となった事象活動となる。未然回避フェーズ250-10は、システムの運用中に障害が発生する前に障害発生を予知したり、あるいは障害が起きる可能性の増大を検出すると、障害を回避するように対応動作するフェーズである。障害の予知が障害の発生予想時刻の充分に前であれば効果的な対策が打てる。例えばシステムの資源を制限してスループットを下げてシステムダウンを回避したりシステムダウンまでの時間を稼いだりすることが行われる。直前に予知した場合には障害の影響の最小化に努力することになる。また、原因解析に有効な、障害に至るまでのシステムの内部情報を記録することができる。予知のための具体的な方法としては、過去の障害パターンから類似の障害を判別することなどがある。未然回避シナリオはスクリプトとして事前に記述され、オペレータやシステム管理者と協調して未然回避動作が実行される。迅速対応フェーズ250-09は、障害が起きた時にその影響を最小化するためのフェーズである。障害に対する迅速対応のシナリオはスクリプトとして事前に記述されており、自動的に行われるのが望ましい。しかしながら、想定しない障害に対応しなければならない場面もある。対応分野や領域ごとの目的に応じたサービス継続のための緊急対応計画責任者や対応組織、手順、エスカレーションパスなどが記されているを事前に立てて、ステークホルダ間で合意しておくことが求められる。当該計画の指示に基づきオペレータやシステム管理者と協調して迅速に障害による影響を最小化することになる。すなわち、障害を分離して影響の局所化を行い、サービス全体のダウンを回避する。そのために障害が発生したアプリケーションやシステムの一部分のオペレーションを中断し、リセットし、その後にオペレータやシステム管理者による復帰活動が行われる。原因究明フェーズ250-08は、障害対応サイクルP301と変化対応サイクルP300に関連したフェーズである。サイクルにより深さの違う判断がなされる。障害対応サイクルP301では、どのような迅速対応が可能であるかを見極めることを目的とした原因究明がおこなわれる。その結果によっては変化対応サイクルP300が開始される。説明責任遂行フェーズ250-05では、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者、社会に対し、障害状況、迅速対応、今後の見通しなど説明する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データベース特にDCase記述と、システム監視記録が説明責任遂行に大いに役立つ。変化対応サイクルP300に関して概説する。変化対応サイクルP300はステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクルである。このサイクルにおける主要なフェーズは、システム変更のための要求抽出リスク分析250-11、ステークホルダ合意250-07、設計実装検証テスト250-02である。大きな変化に対応する場合は説明責任遂行250-05が必須となる。障害対応サイクルP301における原因究明フェーズ250-08の実行の結果、システムの根本的な改良の要求が発生した場合も、変化対応サイクルP300が開始される。要求抽出リスク分析フェーズ250-11は目的や環境の変化によりステークホルダからの要求が変化新規の要求も含むした場合、あるいは障害発生に迅速に対応した後、原因究明を行った結果、システムを変更する必要がある場合が始まる。いずれの場合も、事業主のサービス目的をベースにユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出する。また同時に、サービス目的からシステムのサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。ステークホルダ合意フェーズ250-07では、何をどのように変更するのかを、すべてのステークホルダに分かりやすく、誤解のないように記述し、ステークホルダ間の議論を経て、合意をDCaseとして記述する。またサービス継続シナリオを作成し、その実行手続きであるスクリプトを作成する。要求抽出リスク分析フェーズ250-11と当該ステークホルダ合意フェーズ250-07が要求マネジメントプロセス250-01を構成する。設計実証検証テストフェーズ250-02は、いわゆる設計開発のプロセスである。ここでは、これまで多くの研究がなされ、多くの手法やツールが出されている。説明責任遂行フェーズ250-05では、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか変化するのかを説明する。また、日常のサービス遂行状況や設計開発保守運用プロセスに関する説明が必要なときもこれに対応する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データベース250-06に記録されている特にDCase記述が説明責任遂行に大いに役立つ。4.DEOSアーキテクチャ前記DEOSプロセスは広範なオープンシステムに対するディペンダビリティを実現するための反復的プロセスを提供している。このプロセスをより具体的に対象とするシステムに適用した場合、対象のカテゴリー毎にプロセス実行のためのアーキテクチャを考える必要がある。本実施例では、組込みシステムを含む現代の大規模かつ複雑なソフトウェアシステムへの適応を念頭に考案されたアーキテクチャDEOSアーキテクチャと呼ぶについて述べる。前記DEOSプロセスと当該DEOSアーキテクチャを並べて眺めるとDEOSプロセスが実際のシステムでどのように実行されるかが理解できる。図16を用いて、当該DEOSアーキテクチャに関して説明する。当該アーキテクチャは次の構成要素から構成される。1要求抽出リスク分析フェーズを支援するツール群260-01101-05、2ステークホルダ合意フェーズを支援する合意形成支援ツール群260-02101-05、3合意の記述であるDCaseとサービス継続シナリオの実行手続きであるスクリプト図中ではDScriptとして記載を含む合意記述データベース250-06、4DEOS実行環境260-03、5プログラム検証ツールとベンチマーキングならびにフォールトインジェクションテストのためのツール群を含むDEOS開発支援ツール260-04。要求抽出リスク分析フェーズ250-11は事業主のサービス目的260-05を基にユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出し、想定される障害に対するサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。ステークホルダ合意フェーズ250-07は合意を形成するための方法と合意記述の記法に基づいて合意内容をDCaseとして記述する。そのためのツールがDCaseEditor260-06ならびにDCaseViewer260-07である。また、サービス継続シナリオに基づいた実行手続きスクリプト260-08も作成される。当該スクリプトはDEOSアーキテクチャにおいてDCase記述とアプリケーションプログラムの実行を動的に結合する役割を果たしている。当該スクリプトには後述のスクリプトエンジン図中ではDScriptEngineとして記載が実行するシナリオが書かれている。そのシナリオはDEOS実行環境260-03に対して、1いつ、どのようなログ情報を収集するかを指示し、また、2障害発生時においては障害に対してどのように対処するかを指示している。この時、エスカレーションルールに従ってオペレータの介入を指示する場合もある。このように、当該スクリプトは動的かつ双方向に情報を交換することによりアプリケーションプログラムの実行を柔軟に制御し、オープンシステムディペンダビリティの達成に寄与している。DEOS実行環境260-03はステークホルダ合意に基づくディペンダビリティを実現するサービスを提供するための実行環境であり、次のサブシステムから構成される。DVisorは対象システムの再構成のため、システムの構成要素の各々の独立性を担保する仕組みSystemContainerを提供する。あるSystemContainer内における異常や障害が他のSystemContainerに波及することを抑える働きを担っている。DApplicationManagerは複数のアプリケーションの独立性を担保する仕組みApplicationContainerを提供し、各アプリケーションのライフサイクル生成、起動、更新、停止、削除を管理し制御する。DApplicationMonitorはアプリケーションの動作監視機能を提供し、DCaseモニタノードの記載に従ってエビデンスを収集し、DBoxに蓄積する。DSystemMonitorはシステムオペレーティングシステムやランタイムサポートを含むの動作監視機能を提供する。DApplicationMonitor同様にDCaseモニタノードの記載に従ってエビデンスを収集し、DBoxに蓄積する。DBoxはエビデンスを始め、OSD実現に有益な情報を安全確実に記録する。DScriptEngineはDScriptを安全確実に実行する役割を担い、DApplicationManager、DApplicationMonitor、DSystemMonitorを制御する。DEOS開発支援ツール260-04は事業目的や事業継続シナリオに基づいて決められた機能仕様、テスト仕様、ベンチマーキングシナリオ、さらにはログ仕様に基づいてプログラムを設計し、開発し、検証し、ベンチマーキングを行い、テストを行うための開発支援ツール群である。例えば、型理論ならびにモデル検証に基づいたソフトウェア検証ツール、ベンチマーキング並びにフォルトインジェクション機能を備えたディペンダビリティテスト支援ツール等がある。前記DEOSプロセスを適用することにより享受できる最大の利点は、ステークホルダ間で要求の変化に対する合意議論を充分に行うことができ、合意結果や、その結論に至った理由や、議論の経緯をDCaseに記録することができる点である。システム開発時にDCase記述を用いることにより、前記DEOSアーキテクチャと連携して、障害時に適切かつ迅速な対応を取ることが可能なシステムを設計することができる。またDCase記述があることにより、障害の原因究明や説明責任を果たすことがより容易になる。前記DEOSプロセスのもう一つの利点は、要求が適切に抽出されリスクが充分検討されたのちに、システムの変更が実行される点である。それぞれのステークホルダはシステムの状態をどんな時点でも、それぞれの観点で知ることができる。これによりシステムを簡潔かつ強力に管理運用することができる。一方、要求の数は膨大である。DCaseEditor260-06やDCaseViewer260-07などのツールが要求マネジメントにおける作業を軽減する。前記DEOSアーキテクチャを具現化したDEOS実行環境260-03は、モニタリング機能を備え、DCaseを基に、解析に必要なシステムやアプリケーションの実行状態の監視と記録を実行する。当該実行環境はこの監視記録とスクリプトに従って障害時の迅速対応を実行する。またDCase記述や監視記録から得られた情報をエビデンスとして原因分析や説明責任を遂行する。スクリプトとスクリプトエンジンはDCaseと当該実行環境の橋渡しを果たしており、この仕組みにより、システムの自動的、あるいは必要であればオペレ―タを介したDCase記述に基づく柔軟な対応を可能にする。また前記DEOSアーキテクチャは、あるモジュールにおける障害が他のモジュールに伝搬することを隔離する機能を提供する。同様にシステムのセキュリティを守るために外部からの侵入を検知する機能も提供する。またディペンダビリティ達成のための、実行前にプログラムを検証するツール、パフォーマンスを測定するツール、フォルトを埋め込んで異常時の振舞いをテストする開発ツール等も提供する。上記の仕組みや機能を利用することにより、前記DEOSプロセスと前記DEOSアーキテクチャは、継続的な障害回避のための能力を備え、障害時には適切かつ迅速な対応をして、その影響を最小限とする。またサービスを継続し、説明責任を遂行することができる。前記DEOSプロセスと前記DEOSアーキテクチャはオープンシステムディペンダビリティを達成するための初めての取り組みである。5.実行ランタイム環境図17を用いて本発明における一実施例に係る前記DEOSプロセスを構成する変化対応サイクルP300と障害対応サイクルP301の一連の手順を説明する。当該両サイクル共に通常は通常運用S302の状態にある。変化対応サイクルP300において、ビジネス環境の変化等の環境の変化によるステークホルダ要求の変更、開発途中における要求の変更、及び/又はシステム運用時における要求の変更が起こると、変化対応サイクルP300は環境変化S300-01の状態に遷移する。まず、要求の変更S300-02をワークスペースコンピュータ101図1参照の解析ツール部101-03を用いて行う。ここではステークホルダ群からの要求を抽出後に、当該要求の変更がランタイムコンピュータ102に与える影響を分析したり、具体的な変更手段を分析したり、変更箇所を分析したりする。次に、ディペンダビリティ記述データの変更S300-03を編集ツール部101-02及び/又は開発ツール部101-04を用いて、要求の変更S300-02での分析結果を基にして行う。ここでは、ソフトウェアSWにその結果が反映される。次に、変更が要求通りであることを、エビデンス計測S300-04にて、検証ツール部101-01を用いて確認する。最後に、ソフトウェアSWをデプロイメントS300-05にてランタイムコンピュータ102に導入する。その後、変化対応サイクルP300は通常運用S302になる。また、障害対応サイクルP301において、ランタイムコンピュータ102図1参照に障害が発生した場合には、障害発生S301-01の状態に遷移する。まず、対応策抽出S301-03においてランタイムコンピュータ102を停止させることなく、当該障害に対応する対応策を抽出する。次に、緊急対応S301-04にて当該対応策を実行することで、ランタイムコンピュータ102におけるモデルに基づく処理を継続させる。次に、記録S301-05では当該緊急対応を記録部102-02により記録する。ここでは当該障害に関連する情報も記録部102-02により記録される。ランタイムコンピュータ102はこの時点で継続されていることが望ましいが、障害によっては当該対応策でも継続が不可能な場合がある。継続不継続のいずれの場合でも原因究明S301-06を行う。これにより、当該障害の原因、および、ランタイムコンピュータ102がモデルに基づく処理が不継続の場合にはその原因が究明される。その結果次第では、要求の変更をともない、変化対応サイクルP300を環境変化S300-01の状態に遷移させる。一方、障害対応サイクルP301において、故障あるいは故障の予兆が見つかった場合、あるいは障害の予兆が見つかった場合には、障害予兆S301-02の状態に遷移する。故障あるいは故障の予兆の発見はランタイムコンピュータ102のモニタリング部102-03によりなされる。障害の予兆の発見も当該モニタリング部102-03によってなされる。具体的には、ランタイムコンピュータ102のバイナリ実行部110における各種の計算資源の消費履歴を調べることによって可能である。例えば、メモリ残量が一定時間内で減少を続けている場合には近い将来メモリ不足で計算が停止することがわかる。まず、対応策抽出S301-03においてランタイムコンピュータ102における処理を停止させることなく、前記故障あるいは故障の予兆の発生、あるいは障害の予兆に対応する対応策を抽出する。次に、緊急対応S301-04にて当該対応策を実行することで、ランタイムコンピュータ102を継続する。次に、記録S301-05では当該緊急対応を記録部102-02により記録する。ここでは当該障害に関連する情報も記録部102-02により記録される。ランタイムコンピュータ102におけるモデルに基づく処理はこの時点で継続されていることが望ましいが、障害によっては当該対応策でも継続が不可能な場合がある。継続不継続のいずれの場合でも原因究明S301-06を行う。これにより、前記障害の原因、および、ランタイムコンピュータ102におけるモデルに基づく処理が不継続の場合にはその原因が究明される。その結果次第では、要求の変更をともない、変化対応サイクルP300を環境変化S300-01の状態に遷移させる。なお、上述のように、前記変化対応サイクルP300と障害対応サイクルP301は同時に存在する。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100は、前記ディペンダビリティ記述データを備えるシステムにおいて、環境の変化に起因するステークホルダの要求の変更、システム開発途中における要求の変更、及び/又はシステム運用時における要求の変更に対処するためのプロセスと、システム運用時におけるシステムが提供するサービスを障害発生に際しても継続するように対処し、及び/又はシステム運用時におけるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスという2つの手段を同時に備えていてもよい。このように、前記ディペンダビリティ維持装置は、不完全性と不確実性とを潜在的に有するオープン環境において、環境の変化に起因するステークホルダの要求の変更、システム開発途中における要求の変更、及び/又はシステム運用時における要求の変更に対処するためのプロセスと、システム運用時におけるシステムが提供するサービスを障害発生に際しても継続するように対処し、及び/又はシステム運用時におけるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスという2つの手段を備えることにより、従来の開発フェーズと運用フェーズの垣根を無くし、ステークホルダのアカウンタビリティ達成を可能にすると共に、ディペンダビリティを維持することが可能となる効果を奏する。また、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301の少なくとも何れか一方を実行するように構成されても良い。障害対応サイクルP301において、障害発生S300-01の状態に遷移することによる一連のステップは制御工学におけるフィードバック処理に相当し、障害予兆S300-02の状態に遷移することによる一連のステップは制御工学におけるフィードフォワード処理に相当する。従って、当該フィードバック処理の結果を学習することで、対応モデルを構築し、当該フィードフォワード処理に役立てるように構成することもできる。また、その際の当該モデルがディペンダビリティ記述データへの変更として記録することができるように構成しても良い。また、当該フィードフォワード処理においては、他のシステムにおける対応モデルを上記ディペンダビリティ記述データに記述することで、ステークホルダ群が合意した状態で当該モデルに対応する障害予兆に対してプロアクティブな回避処理を行うように構成することもできる。オープン環境において対象システムのディペンダビリティを継続的に維持するためには、要求変化や環境変化に対応して十分に検討して対処する変化対応サイクルP300と、運用中の障害発生に迅速に対応する障害対応サイクルP301との両方が必要である。そこで、上記のように構成することにより、変化対応サイクルP300および障害対応サイクルP301の少なくともいずれか一方において、対象システムのディペンダビリティの価値を示す評価値を求めることができる。したがって、例えば、変化対応サイクルP300において、要求変更に伴ってディペンダビリティ記述データを変更するときに、評価値に基づいて、ディペンダビリティ記述データの変更案の適否を判断することが可能となる。また、例えば、障害対応サイクルP301において、対象システムの運用時に対象システムの状態を、評価値に基づいて判断することが可能となる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となる。6.変化対応サイクル図18は、図17に示したワークスペースコンピュータ101で作業される変化対応サイクルP300における、ステークホルダ間での合意形成処理S400、要求変更の実装処理S401、アカウンタビリティ処理S402の3つのステップを図示している。ステークホルダ間での合意形成処理S400は要求の変更S300-02とディペンダビリティ記述データの変更S300-03と関係している。ステークホルダ間での合意形成処理S400は、要求変更の内容を理解するステップ要求変更の理解S400-01から始まる。それには、例えば、IEEEStd8301998IEEERecommendedPracticeforSoftwareRequirementsSpecificationに準拠したSRSソフトウェア内部仕様書を分析する。次に、影響分析S400-02で既存のディペンダビリティ記述データに対する変更点を列挙する。最後に、当該変更点をディペンダビリティ記述データの変更S400-03において当該ディペンダビリティ記述データの変更として反映させる。これらのステップはステークホルダ間で合意S400-04されるまで繰り返される。また、要求変更の実装処理S401はディペンダビリティ記述データの変更S300-03とエビデンス計測S300-04と関係している。要求変更の実装処理S401は、設計S401-01のステップから始まる。設計S401-01では開発ツール部101-04を利用して要求変更を実際のコードに変換するためのソフトウェア設計が、例えば能力成熟度モデル統合CapabilityMaturityModelIntegrationCMMIに従って行われる。次に、実装S401-02では、設計S401-01での設計を開発ツール部101-04を利用してソフトウェアSWに変換する。次に、テストS401-03では、全ステップでのソフトウェアSWを検証ツール部101-01を用いてテスト、検証する。これらのステップはテストS401-03での検証が全てOKとなるまで繰り返される。検証が全てOKとなると、導入S401-04で当該ソフトウェアSWをランタイムコンピュータ102に導入する。また、アカウンタビリティ処理S402はエビデンス計測S300-04とデプロイメントS300-05と関係している。アカウンタビリティS402は、ベンチマーク等収集S402-01のステップから始まる。ベンチマークはランタイムコンピュータ102で実行され計測されても良いし、ランタイムコンピュータ102をシミュレーションする環境上で実行され計測されても良い。次に、収集されたベンチマークデータが要求を満足しているか検証されるエビデンス検証S402-02。最後に、ステークホルダは当該検証されたデータをエビデンスとして必要に応じて情報開示する情報開示S402-03。なお、情報開示S402-03により、ステークホルダがアカウンタビリティを達成S402-04することができる。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ワークスペースコンピュータ101は、上記環境の変化に起因するステークホルダの要求の変更、システム開発途中における要求の変更、及び/又はシステム運用時における要求の変更に対応するためのプロセスにおいて、それら要求を入力として、当該要求の変更の発生を起点とした一連のステップから構成されるループを形成する当該プロセスにおいて、当該要求の変更を確実に実装しシステム運用しサービスを提供できるようにステークホルダ間で要求の変更の合意を形成するステップと、当該要求の変更を実装し検証しシステム運用するステップと、当該要求の変更によるシステム運用とサービス提供によりステークホルダがアカウンタビリティを達成するステップという3つのステップを実行しても良い。7.障害対応サイクル迅速対応図19は、障害対応サイクルP301のうち、障害発生検出時の2つの処理を示すフローチャートである。なお、図19における障害対応サイクルP301は図17の再掲である。障害発生S301-01はモニタリング部障害発生検出手段102-03によって障害の発生が検出されると当該状態に遷移する。モニタリング部102-03は、例えば、D値が所定の変動許容範囲より悪化したとき、障害発生を検出する。障害発生検出時の障害対応サイクルP301には2つの機能が関係している。システム再構成処理S502とアカウンタビリティ処理S503である。システム再構成処理S502は対応策抽出S301-03と緊急対応S301-04に関係している。システム再構成処理S502はサービス継続判断S502-01から始まる。ここでは、障害に該当する部分のディペンダビリティ記述データを抽出する。当該ディペンダビリティ記述データからシステム再構成シナリオが抽出可能である場合にはS502-01でYES、次のステップに進む。なお、ディペンダビリティ記述データからシステム再構成シナリオが抽出不可能である場合にはS502-01でNO、継続不可能と判断して、ディペンダビリティ記述データの変更抽出処理S800図27を実行する。システム再構成シナリオはシステム設計時点であらかじめ典型的なケースに関しては組み込んでおいても良い。例えば、後述のアプリケーションコンテナあるいいはシステムコンテナを再起動するシナリオはその一例である。また、当該再構成シナリオを後述同様にディペンダビリティ記述データにおけるノードに実行可能なプログラムを関連つけても良い。いずれの手法においても、当該再構成シナリオが抽出できない場合には、ディペンダビリティ記述データを変更するために、変化対応サイクルP300を実行する準備をする。また、当該再構成シナリオを後述のスクリプトとして記述し、ディペンダビリティ記述データに関連つけても良い。次に、障害部位隔離S502-02では当該抽出されたシナリオに従って障害部位を隔離し、ディペンダビリティ記述データの違いをランタイムコンピュータ102に反映させ、次ステップに進む。次に、サービス継続S502-03では当該シナリオに従って隔離された部位の代替機能が当該シナリオによって起動され、サービスが継続されるS502-04。一方、アカウンタビリティ処理S503は記録S301-05と原因究明S301-06に関係している。アカウンタビリティ処理S503は障害に関係するログを記録するS503-01ことから始まる。次に、前記シナリオに従って再構成されたランタイムコンピュータ102のエビデンスを収集するS503-02。ここでのエビデンスとはシステム再構成によってランタイムコンピュータ102がディペンダビリティ記述データに従って適切に動作していることの記録である。次に、障害原因検出S503-03に進む。ここでは、障害に関係する前記ログS503-01、前記エビデンスS503-02、及び前記障害に関係したディペンダビリティ記述データをまとめたものである。本実施の形態では、当該まとめをステークホルダによるアカウンタビリティの達成とする。なお。これらのステップS503-01及びS503-02は並列に処理されても良い。図20にモニタリング部102-03による障害発生検出処理の一例を示す。図20aはディペンダビリティ記述データの一部510を示す。ディペンダビリティ記述データを作成する際に、実行時に状況が変化するデータは、モニタノードによって実行時にモニタリングが必要であることを明示しておく。ノード510-01は正常なDBSのHDDアクセスに関する。当該ノードは2個に分岐され、すなわち、データベースシステムがHDD装置に対して正常にアクセスしている状態を2個のノードにブレークダウンして、その条件を記述している。具体的には、ノード510-02はHDDの残容量に関する。また、ノード510-03はHDDの転送量に関する。ここで、本例では、これら2ノードのエビデンスとして前記モニタノードを導入する。図20aでは、ノード510-04とノード510-05がモニタノードである。ノード510-04はHDDの残容量をモニタする。ノード510-05はHDD転送速度をモニタする。ディペンダビリティ記述データにおけるモニタノードは、対象のシステムを外部からモニタリング可能な場合にはモニタリング部102-03が備える監視モジュール群後述を利用して対象のシステムをモニタリングする。一方、対象のシステムを外部からモニタリング不可能な場合には、対象のシステムに後述のプログラムを導入する手順に従って監視モジュールを送り込むことでモニタリングを行う。そして、実行時のモニタリング結果をディペンダビリティ記述データの記述と比較することにより、変動許容範囲を超える差分の場合には、設計時の基準と異なる振る舞いとして異常として特定する。また、ディペンダビリティ記述データの上位ノードを参照することで、複合的な異常により上位ノードのディペンダビリティが満たされない状況を把握できる。さらに、個々のシステム内や複数のシステム間の障害箇所を突き合わせることにより、障害発生箇所を絞り込むことができる。図20bにモニタノードを用いて障害検出するためのディペンダビリティ維持システム100の構成例を示す。モニタノードはパターンによって分類することができる。例えば、図20aの2個のモニタノード510-04、510-05はHDD1の2が3であることをモニタリングするという形式を取ることができる。このモニタノードのパターンに対応するように監視モジュール群を予め用意し、モニタノードのパターンと監視モジュールの対応関係をテーブル化しておくことにより、実行時の状態をモニタリングできる。例えば、図20aの2個のモニタノード510-04、510-05に関しては、図21のように対応関係を示すことができる。ここで、図21は、HDD1の2が3であることをモニタリングするというパターンのモニタノードの場合に、2がディスク容量であれば、監視モジュールとしてHDD監視モジュールを利用し、引数として1=HDD識別番号と3=変動許容範囲を指定すれば良いことを示している。ワークスペースコンピュータ101の編集ツール部101-02はディペンダビリティ記述データM1を記述し、さらに、ランタイムコンピュータ102における内部表現であるディペンダビリティ記述データ内部表現M2に変換する。詳細には、ワークスペースコンピュータ101の編集ツール部101-02において、ディペンダビリティ記述データ記述表示ツール511-01がディペンダビリティ記述データM1を記述した後、それを、ディペンダビリティ記述データ変換部511-03によってディペンダビリティ記述データ内部表現M2に変換する。ランタイムコンピュータ102では、ワークスペースコンピュータ101から取得したディペンダビリティ記述データ内部表現M2を更新部102-01がディペンダビリティ記述データ格納部511-05に記録する。また、更新部102-01は、ディペンダビリティ記述データ内部表現M2に基づいて、モニタノードとモニタリング部102-03における各種監視モジュール監視モジュール群511-mとの対応関係をモニタノード/モジュール対応テーブル511-06に記録する。なお、図20bには監視モジュール群511-mの各監視モジュールとして、CPU監視モジュール511-08、HDD監視モジュール511-09、プロセス監視モジュール511-10、が記載されているが、他の監視モジュール511-11があっても良い。モニタリング部102-03における前記監視モジュールによって得られたデータモニタ値は収集部510-13によって集められ、実行状況検証部510-12によって、モニタノード/モジュール対応テーブル511-06に基づき、前記ディペンダビリティ記述データにおけるモニタノードの値として記録される。例えば、ディペンダビリティ記述データの各モニタノードに前記モニタ値の変動許容範囲を対応付けて記載しておき、モニタ値がその変動許容範囲から外れたノードを障害発生ノードとして検出する。また、前記監視モジュール群511-mからのモニタ値はD値計算部102-06においてノードに対するD値の計算に利用される。よって、例えば図20aのディペンダビリティ記述データの一部510では、2個のモニタノード510-04、510-05から取得されたモニタ値が変動許容範囲と比較されるとともに、これに基づいてD値が算出される。また、CPU利用率、メモリ使用量、プロセス死活等は、のOS機能としてあらかじめ備わっており、外部からモニタリング可能なものもあるが、システムA内のある処理Xが正常終了したというような、外部からのモニタリングが難しいものもある。これらは、主に、アプリケーション固有の情報であり、ランタイムコンピュータ102に監視モジュール511-14として組み込む。すなわち、モニタリング対象をモニタリングする監視モジュールが内部にない場合、監視モジュール511-14のように、外部に監視モジュールを設けることができる。この組み込みはシステム構築時であっても良いし、ランタイムコンピュータ102の実行時であっても良い。これにより、実行時のモニタリング結果が変動許容範囲を超えた場合に、ディペンダビリティ記述データのノード単位で異常を特定できる。また、実行時に各々の監視モジュールからモニタリング結果を集める510-04、510-05ことにより、ディペンダビリティ記述データ上のどのモニタノードで変動許容範囲を超えているかを判断できる。つまり、ディペンダビリティの観点から問題の発生を把握できる。すなわち、ディペンダビリティ記述データを当該モニタノードから上位側へ検討することで、どの範囲でディペンダビリティが維持できなくなったかを判断できる。例えば、ノード510-04及びノード510-05のモニタ値が共に変動許容範囲を超えているような状況では、ディペンダビリティを維持できなくなった原因がHDD以外にあるとして、ディペンダビリティ記述データのより上位を探索する。さらに、複数のシステムが相互作用している状況では各々のシステムに関するディペンダビリティ記述データだけではなく、相互作用に関するディペンダビリティ記述データも記述されていれば、適切なモニタノードによってシステム相互間で変動許容範囲を超える振る舞いの部位を絞り込むこと、あるいは特定することができる。前記監視モジュール群511-mはシステムにあらかじめ組み込まれた監視モジュール群であるが、運用中に新たな監視モジュールを組み込む場合、あるいは変動許容範囲の判断が複数のセンサからのデータを考慮しなければ行けなかったり、ログからのデータを解析しなければ行けなかったりする場合には、スクリプトで構成することができる。図22を用いて、スクリプトの構成概要を説明する。スクリプトは1以上の基本動作550-01図ではDTaskとして記載と1以上の制御動作550-02図ではDControlとして記載から構成される。制御動作550-02は変動許容範囲を深刻度で分けて該当する深刻度の基本動作DTaskを実行する。例えば、ハードディスクの残容量の場合には、50の残容量の深刻度を低、75の残容量の深刻度を中、90の残容量の深刻度を高として設定して、制御動作550-02DControlを構成できる。この場合、深刻度高の場合にはDTask1550-03を実行し、深刻度中の場合にはDTask2550-04を実行し、深刻度低の場合にはDTask3550-05を実行する。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを障害発生に際しても継続するように対処するプロセスにおいて、障害の発生を検出する手段モニタリング機能と、障害の発生した部分を隔離する手段隔離機能と、隔離された残りの部分でサービスを継続する手段と、障害の原因を検出する手段原因追及機能と、上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段継続性判断機能とを備えるプロセスにおいて、当該障害の発生を起点とした一連のステップから構成されるループを形成する当該プロセスにおいて、当該障害の発生に際してサービスの停止期間を最小限にするように前記ディペンダビリティ記述データを備える対象システムを再構成するステップと、当該再構成によるシステム運用とサービス提供によりステークホルダがアカウンタビリティを達成することができるステップという2つの処理を実行しても良い。また、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301のうち、少なくとも上記障害対応サイクルP301を実行するとともに、上記障害発生を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段再構成部102-04を備えて構成されても良い。これにより、障害対応サイクルP301を実行するランタイムコンピュータ102において、対象システムの障害発生を検知したとき、ディペンダビリティ記述データに基づいて、当該対象システムを再構成して、対象システムの運用を継続させることができる。そして、ランタイムコンピュータ102は、対象システムの障害発生を、D値に基づいて検知してもよい。例えば、D値が所定の変動許容範囲より悪化したとき、障害発生を検出するようにしても良い。8.障害対応サイクル障害未然回避図23は、障害対応サイクルP301のうち、障害予兆検出時の2つの処理を示すフローチャートである。なお、図23における障害対応サイクルP301は図17の再掲である。障害予兆S301-02はモニタリング部障害予兆検出手段102-03によって障害の予兆、あるいは故障あるいは故障の予兆が検出されると当該状態に遷移する。なお、障害の予兆に関しては各種の手法を組み合わせて実現可能である。例えば、ハードディスクドライブ装置はSMARTの仕組みを使うことで障害の予兆を検出できる。また、モニタリング部102-03は、例えば、D値の時間変化の傾向が所定の基準より悪化したとき、障害予兆を検出する。また、当該モニタリング部102-03は、前記モニタノードでモニタリングされているデータの時間変化の傾向が変動許容範囲を超えている場合に障害予兆として検出する。障害予兆検出時の障害対応サイクルP301には2つの機能が関係している。システム再構成処理S602とアカウンタビリティ処理S603である。システム再構成処理S602は対応策抽出S301-03と緊急対応S301-04に関係している。システム再構成処理S602は障害部位とその影響範囲の同定S602-01から始まる。ここでは、障害の予兆と障害そのものの検出を説明の都合上同一視して障害として扱う。まず、ディペンダビリティ記述データのどの部位が障害かを同定する。そして当該ディペンダビリティ記述データからその影響範囲を同定する。影響範囲はディペンダビリティ記述データのノードを探索することにより同定する。例えば、障害部位に対応するノードが複数ある場合には、それらの共通ノードまでを影響範囲として特定できる。また、ノードにノード間の依存関係が記録されている場合には、当該依存関係を利用しても良い。次に、サービス継続判断S602-02では、当該ディペンダビリティ記述データから抽出される対応シナリオが当該影響範囲を十分にカバーしてサービスが継続できるか、判断される。継続可能の場合にはS602-02でYES、障害部位隔離S602-03に進む。なお、ディペンダビリティ記述データから対応シナリオが抽出できない場合にはS602-02でNO、継続不可能と判断して、ディペンダビリティ記述データの変更抽出処理S800図27を実行する。当該変更抽出処理S800は、サービス継続判断S602-02にて継続可能の場合であっても、当該障害予兆の内容によっては実行された方が良い状況もあるので、一実施例として当該変更抽出処理を実行するように構成しても良い。次に、障害部位隔離S602-03では、抽出された対応シナリオに従って障害部位を隔離する。次に、サービス継続S602-04に進み、システム再構成処理S602を終了する。この時点でランタイムコンピュータ102によるサービスは継続されているS602-05。一方、アカウンタビリティ処理S603は記録S301-05と原因究明S301-06に関係している。アカウンタビリティ処理S603は内部状態の記録S603から始まる。ここでは、前記障害に関連したディペンダビリティ記述データ、及び当該ディペンダビリティ記述データに関連したランタイムコンピュータ102の内部の状態を記録する。次に、システム再構成処理S602後のエビデンスを収集するS603-02。ここでのエビデンスとはシステム再構成によってランタイムコンピュータ102がディペンダビリティ記述データに従って適切に動作していることの記録である。なお、本実施の形態では、当該エビデンスの収集をもってステークホルダによるアカウンタビリティの達成とするS603-03。前記緊急対応S301-04は上記スクリプトDScriptを用いて処理しても良い。図24に一例を示す。当該スクリプトDScriptは図4b記載のWEBサービスの再起動のシナリオ例であり、6個の基本動作DTaskから構成されている。当該シナリオは上記DEOSプロセスにおける要求抽出リスク分析フェーズ250-11におけるサービス継続シナリオから導出される。ステークホルダは当該シナリオに関して合意している。当該サービス継続シナリオは要求抽出リスク分析フェーズを支援するツール群260-01を用いて記述され、図24の形式で記述され、スクリプトに変換され、ステークホルダ合意によって電子署名される。スクリプトがラインタイムコンピュータ102内部の後述のスクリプトエンジン部710102-07において実行される際には、当該スクリプトに附随された電子署名が検証される。電子署名が有効でない場合にはスクリプトは実行されない。さらに、スクリプトの実行に際しては、その権限を確認するように構成しても良い。すなわち、誰がどのスクリプトの操作を実行可能かを確認するように構成可能である。その場合には権限を有しない状況では当該スクリプトは実行されない。さらに、スクリプト自体を暗号化してランタイムコンピュータ102内部に格納するように構成しても良い。これらのセキュリティに関する施策により、当該スクリプトが原因となるセキュリティ違反を防止することができる。図25を用いてランタイムコンピュータ102に関するソフトウェアの階層構造の一例を説明する。図25では3個のCPUコア701701-01~701-03を有するマルチコア構成例を示している。なお、図25では周辺デバイスは省略している。CPUコアの上位層にはシステムコンテナ提供部702がある。これは、隔離部102-05図1の一部であり、上位層に対して複数のOSカーネル711を動作可能にする、隔離されたコンテナを提供する。また、図25では各々のCPUコア701に対してそれぞれ1つのシステムコンテナ716、718、及び720が割り当てられているが、複数のシステムコンテナを1つのCPUコア701に割り当てても良いし、1つのシステムコンテナに対して複数のCPUコア701...を割り当てても良い。CPUコア701-01にはシステムコンテナ716を割り当て、そこではOSカーネル711上に、システムモニタ部704、再構成部102-04、システム記録部706、ディペンダビリティ記述データ処理部707が配置される。システムコンテナ716はランタイムコンピュータ102に1つ存在する。システムモニタ部704はモニタリング部102-03図1の一部でありランタイムコンピュータ102におけるシステム機能をモニタする。特に他のシステムコンテナ図25ではシステムコンテナ718と720のOSカーネル711をモニタする。また、当該システムモニタ部704に学習機能を持たせるように構成しても良い。例えば、対象システムにおけるシステム機能をモニタする際に、そのデータ構造に対する整合性をモニタするように構成する場合に、当該システム機能に対応した仕様書やソースコードから整合性のための条件を自動生成するように構成することができる。実行時に当該条件を学習することで、当該データ構造の全てをモニタしないでも、または、当該データ構造が変更されても当該モニタの仕組みを変えないでモニタ機能を継続することができる。再構成部102-04は、他のシステムコンテナの再構成を行う。具体的には、既に存在するシステムコンテナを停止させ、破壊し、新しい構成でシステムコンテナを作り出し、当該構成に従ってOSカーネルを始めとする機能を配置し起動する。システムコンテナが破壊されるときには、当該システムコンテナの内部状態を、システム記録部706を用いて記録しても良い。システム記録部706は記録部102-02図1の一部であり、ランタイムコンピュータ102の内部状態を記録する。ディペンダビリティ記述データ処理部707は更新部102-01図1の一部であり、ワークスペースコンピュータ101で生成されたソフトウェアSWの内部にあるディペンダビリティ記述データをランタイムコンピュータ102全体のディペンダビリティ記述データに取り込み、ディペンダビリティ記述データを処理するためのシナリオを抽出しランタイムコンピュータ102を、再構成部102-04を利用して再構成する。一方、CPUコア701-02にはシステムコンテナ718を割り当て、そこではOSカーネル711上に、アプリケーションモニタ部708、アプリケーション記録部709、スクリプトエンジン部710、アプリケーションコンテナ提供部712、アプリケーション管理部713乃至714、そしてアプリケーション群を配置している。ここで、アプリケーションコンテナとは、前記システムコンテナ1個に対して1個以上存在し、1個以上のアプリケーションをグループ化し、アドレス空間の独立、名前空間の独立、及びCPUスケジューリングの独立を実現し、アプリケーションコンテナ提供部712により提供される。図25ではシステムコンテナ718にアプリケーションコンテナ717及び719の2個を配置している。アプリケーションモニタ部708はモニタリング部102-03図1の一部であり、アプリケーションコンテナ内部をモニタする。アプリケーション記録部709は記録部102-02図1の一部であり、アプリケーションコンテナの内部状態を記録している。アプリケーションコンテナ717にはアプリケーション管理部713を配置し、1個以上のアプリケーションが利用する。同様にアプリケーションコンテナ719内部にはアプリケーション管理部714を配置し、1個以上のアプリケーションが利用する。システムコンテナ720の内部構成はシステムコンテナ718と同様である。そのため、説明および図25中の表示を省略する。図26にランタイムコンピュータ102の隔離部102-05図1が実現する各隔離項目に関しての機能要件の一例をまとめる。これらの隔離項目は一部を選択して必要な機能要件のみを実現しても良い。例えば、前記システムコンテナは、これら項目の全部が実現されているし、アプリケーションコンテナはアドレス空間、名前空間、及びCPUスケジューリングの3項目が実現されている。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスにおいて、前記ディペンダビリティ記述データを備えるシステムの内部状態を記録する手段ロギングと、当該記録された内部状態から前記ディペンダビリティ記述データを備えるシステムの障害の予兆を検出する手段と、前記ディペンダビリティ記述データを備えるシステムの当該検出された障害に対応する部分を同定する手段と、当該検出された障害が上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段とを備えるプロセスにおいて、当該障害の発生の検出を起点とした一連のステップから構成されるループを形成する当該プロセスにおいて、当該検出された障害発生、あるいは障害の予兆によるサービスの停止を回避する目的で前記ディペンダビリティ記述データを備えるシステムを再構成するステップと、当該再構成によるシステム運用とサービス提供によりステークホルダがアカウンタビリティを達成することができるステップという2つの処理を実行しても良い。また、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301のうち、少なくとも上記障害対応サイクルP301を実行するとともに、上記障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段再構成部102-04を備えて構成されても良い。これにより、障害対応サイクルP301を実行するランタイムコンピュータ102において、対象システムの障害予兆を検知したとき、ディペンダビリティ記述データに基づいて、当該対象システムを再構成して、対象システムの運用を継続させることができる。そして、ランタイムコンピュータ102は、対象システムの障害予兆を、D値に基づいて検知してもよい。例えば、D値の時間変化の傾向が所定の基準より悪化したとき、障害予兆を検出するようにしても良い。さらに、ランタイムコンピュータ102は、対象システムの障害予兆を、前記モニタノードでのモニタリングデータに基づいて検知してもよい。例えば、当該モニタリングデータの時間変化の傾向が所定の基準より悪化し変動許容範囲を超えたとき、障害予兆を検出するようにしても良い。9.障害対応サイクルからの変化対応サイクルの起動図27は、ディペンダビリティ維持システム100におけるディペンダビリティ記述データの変更抽出処理の手順を示すフローチャートである。上述したサービス継続判断S502-01図19、あるいは、サービス継続判断602-02図23において、サービス継続判断がNOすなわち継続不可能と判断されたときには、ディペンダビリティ記述データの変更抽出処理S800を実行する。まず、障害部位に関するディペンダビリティ記述データを抽出するS800-01。次に、そのディペンダビリティ記述データにおけるリーフノードでテストと関連のあるノード全てにおいて、S800-03~S800-05の処理を実行するS800-02。例えば、図5においては、ノード群202-06~202-13が該当する。そこで、当該ノード群202-06~202-13に対応するテストを実行し計測するS800-03。既にエビデンスとしての結果は存在しているので、ここでの計測結果と比較することでエビデンスからの差異が変動許容範囲内か否かが判断されるS800-04。変動許容範囲外の場合にはNO、異常状態であるとして当該ノードの識別情報例えば、ノード番号を記録するS800-05。全ノードに対して前記処理を終えると、前記識別情報が記録されたノードを変更する指示をワークスペースコンピュータ101に送りS800-06、処理を終了するS800-07。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、前記障害対応サイクルP301において、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスの継続が不可能と判断された場合、前記変化対応サイクルP300において前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記障害対応サイクルP301において記録又は検出された情報から前記ディペンダビリティ記述データを備えるシステムのディペンダビリティ記述データの変更を前記障害対応サイクルP301へ要求として入力するステップを実行しても良い。また、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ランタイムコンピュータ102は、上記障害発生または障害予兆を検知し、上記対象システムの停止が不回避であるとき、上記変化対応サイクルP300を実行する装置ワークスペースコンピュータ101に、上記ディペンダビリティ記述データの変更の要求を送信する変更要求送信手段変更送出部902-02を備えて構成されても良い。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301のうち、少なくとも上記変化対応サイクルP300を実行するとともに、上記障害対応サイクルP301を実行する装置ランタイムコンピュータ102から、上記ディペンダビリティ記述データの変更の要求を受信したとき、上記ディペンダビリティ記述データを変更するように構成されても良い。これにより、障害対応サイクルP301を実行するランタイムコンピュータ102において、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であると判断したとき、変化対応サイクルP300を実行するワークスペースコンピュータ101に、ディペンダビリティ記述データの変更の要求を送信することができる。なお、ランタイムコンピュータ102は、障害発生または障害予兆により、対象システムの停止が不回避であるか否かを、D値に基づいて判断しても良い。そして、ワークスペースコンピュータ101は、ランタイムコンピュータ102からディペンダビリティ記述データの変更の要求を受信したとき、当該要求に応じて、上記ディペンダビリティ記述データを変更する。したがって、ランタイムコンピュータ102とワークスペースコンピュータ101とが連携して、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であれば、ディペンダビリティ記述データを変更するというプロセスを円滑に実行することができる。よって、オープン環境において、対象システムのディペンダビリティを継続的に維持することが可能となる。なお、前記記載の構成において、対象システムの停止が回避可能である場合においても、障害予兆の内容によっては前記記載のディペンダビリティ記述データの変更手順を実行するように構成しても良い。10.障害対応サイクルと変化対応サイクルとの連携図28は、ワークスペースコンピュータ101とランタイムコンピュータ102とのディペンダビリティ記述データを介した情報交換を示す機能ブロック図である。ワークスペースコンピュータ101における編集ツール部101-01は、主に3個の構成要素を持つ。ディペンダビリティ記述データ編集部900-01は、ディペンダビリティ記述データを記述し、編集し、記録する。当該ディペンダビリティ記述データ編集部900-01は、図16に記載のDCaseEditor260-06として構成しても良い。なお、ディペンダビリティ記述データ編集部900-01として、特願2010263681に記載のツールを用いても良い。当該特願2010263681では、要求ベースにディペンダビリティ記述データを記述する際に、常に着目ノードが表示の中心になるようにディペンダビリティ記述データを表示することで詳細化の流れを簡素にしている。ディペンダビリティ記述データ組込部900-02は、ディペンダビリティ記述データ編集部900-01にて作成されたディペンダビリティ記述データM1を内部表現に変換して、ディペンダビリティ記述データM2正確には、ディペンダビリティ記述データ内部表現M2;図3のディペンダビリティ記述データ104-02に相当を生成する。そして、ディペンダビリティ記述データ組込部900-02は、ソフトウェアSWに、当該ソフトウェアSWに対応したあるいは関する前記ディペンダビリティ記述データM2を組み込む。デプロイメント部900-03は当該ソフトウェアSWをランタイムコンピュータ102に導入する。ここで、ディペンダビリティ記述データM2には、ディペンダビリティ記述データ編集部900-01によって、各エビデンスノードについて、モニタされるモニタ値に対する変動許容範囲が記録される。これにより、ランタイムコンピュータ102のモニタリング部102-03では、モニタ値の状態を確認できる。一方、ディペンダビリティ記述データM3には、記録部102-02によって、各エビデンスノードについて、モニタされたモニタ値のすべてあるいは一部が記録される。これにより、ワークスペースコンピュータ101の解析部901-03では、システムに生じた異常の原因を検討することができる。また、ワークスペースコンピュータ101における解析ツール部101-03は、主に3個の構成要素を持つ。ディペンダビリティ記述データ入力部記述データ取得手段901-01はランタイムコンピュータ102からのディペンダビリティ記述データM3を入力とする。データベースアクセス部901-02はランタイムコンピュータ102に導入されているソフトウェア全体に関する複数のディペンダビリティ記述データにアクセスする。データベースは、ワークスペースコンピュータ101に設けられても良いし、ランタイムコンピュータ102に設けられても良いし、ワークスペースコンピュータ101と通信可能な他の装置に設けられても良い。ここでは、入力されたディペンダビリティ記述データM3に関連したディペンダビリティ記述データM4を、当該データベースから抽出する。ディペンダビリティ記述データM4はオリジナルのモデルであり、ディペンダビリティ記述データM3は変更が記載されたモデルである。当該データベースから抽出されるディペンダビリティ記述データM4はディペンダビリティ記述データM3をキーに検索されるが、より広範囲のディペンダビリティ記述データを抽出しても良く、解析部901-03での処理を容易にする。解析部901-03は当該入力されたディペンダビリティ記述データM3とベータベースアクセス部901-02経由で得られるディペンダビリティ記述データM4を解析して、障害原因等を分析し、必要に応じて環境変化S300-01図17、図18の状態に遷移させて、変化対応サイクルP300を実行する。一方、ランタイムコンピュータ102において更新部102-01は、6個の構成要素を持つ。ソフトウェア入力部記述データ取得手段902-01はワークスペースコンピュータ101におけるデプロイメント部900-03からのソフトウェアSWを入力とする。当該ソフトウェアSWは更新部102-01によってランタイムコンピュータ102にインストールされ稼働される。ディペンダビリティ記述データ抽出部902-03はソフトウェアSWに含まれているディペンダビリティ記述データM2正確には、ディペンダビリティ記述データ内部表現M2;図3のディペンダビリティ記述データ104-02に相当を取り出す。構造検証部902-04は、当該取り出されたディペンダビリティ記述データM2の計算機表現としての妥当性を検証する。さらに、必要な機能ライブラリ等がランタイムコンピュータ102に備わっているかを確認する。実行管理部902-05は当該ソフトウェアSWをランタイムコンピュータ102に導入する際に必要な準備を行う。例えば、当該ソフトウェアSWが新しいサービスアプリケーションである場合には、必要な計算資源を見積もり割り当て、アプリケーションコンテナ図25のアプリケーションコンテナ717等を生成し、アプリケーションイメージを当該アプリケーションコンテナ内に構成する。また、変更送出部変更要求送信手段902-02はランタイムコンピュータ102にインストールされたディペンダビリティ記述データM2における変更部分ディペンダビリティ記述データM3をワークスペースコンピュータ101のディペンダビリティ記述データ入力部901-01に送り出す。このとき、変更送出部902-02は、上記変更部分と共に、ディペンダビリティ記述データの変更要求を送出しても良い。変更管理部902-06はランタイムコンピュータ102において、図27に示したディペンダビリティ記述データの変更を管理する。前記において、ワークスペースコンピュータ101とランタイムコンピュータ102は、ディペンダビリティ記述データという計算機表現を介して情報交換する。前者から後者に対してはディペンダビリティ記述データM2を手段とし、後者から前者に対してはディペンダビリティ記述データM3を手段とする。ディペンダビリティ記述データM2はステークホルダ合意に対応したモデルであり、ディペンダビリティ記述データM3は当該ステークホルダ合意がランタイムコンピュータ102において満足されなくなり、その差分を表現したものであり、ステークホルダに対する通知である。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記変化対応サイクルP300と前記障害対応サイクルP301との間での情報交換の手段を有していても良い。11.ディペンダビリティ記述データとの連携図29は、図5に示したディペンダビリティ記述データを、計算機表現の一例としてXMLで記述したリストの一部である。なお、図28におけるソフトウェアSWに組込まれたディペンダビリティ記述データM2、あるいはディペンダビリティ記述データM3は当該XML表記により記述することができる。図30は、ディペンダビリティ維持システム100の構成例であって、ディペンダビリティ記述データデータベースと、ワークスペースコンピュータおよびランタイムコンピュータとの関係を示す説明図である。図30に示すように、ソフトウェアSWに組み込まれているディペンダビリティ記述データM2は、ワークスペースコンピュータ101およびランタイムコンピュータ102とは別体のディペンダビリティ記述データデータベース1000に格納され、ワークスペースコンピュータ101およびランタイムコンピュータ102から利用されても良い。当該データベースは図15に記載の合意記述データベース250-06として構成しても良い。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、前記ディペンダビリティ記述データから変換されたコンピュータで処理可能な形式のデータを、当該ディペンダビリティ記述データを備えるシステムが管理する手段を有することで、前記変化対応サイクルP300におけるステークホルダによる変更の要求の合意のステップによる結果を、確実に当該ディペンダビリティ記述データを備えるシステムに実施する手段を有していてもよい。12.ランタイムコンピュータでのコマンド処理図31に、ランタイムコンピュータ102におけるコマンド実行の処理手順を示す。本実施の形態におけるコマンドとは、あらかじめランタイムコンピュータ102に組み込まれた、当該ランタイムコンピュータ102で実行可能な一連の処理であっても良いし、後述のディペンダビリティ記述データのノードに関連付けられた当該ランタイムコンピュータ102で実行可能なプログラムであっても良い。まず、コマンド実行処理S1100の開始にあたって、処理が開始された旨が記録されるS1100-01。次に、処理を1個以上のコマンド列に分解し、それをチェインとして構成するS1100-02。つづいて、コマンドチェイン中の全コマンドに対してS1100-03、以下のS1100-04、S1100-05の処理が実行される。すなわち、チェイン中のコマンドを1つ実行しS1100-04、正常終了か、異常終了かを判断するS1100-05。そして、全部のコマンドが正常終了の場合にはS1100-05でYES、終了が記録されS1100-07、当該処理は終了するS1100-14。一方、コマンドチェイン中のコマンドが異常終了した場合S1100-06でNO、実行されたコマンドの効果を取り消すためのリカバリチェインが構築されるS1100-08。その後、リカバリチェイン中の全コマンドに対してS1100-09、リカバリコマンドを実行しS1100-10、正常終了か、異常終了かを判断するS1100-11。全リカバリコマンドが正常終了の場合S1100-11でYESには、その旨を記録してS1100-07、当該処理は終了するS1100-14。一方、リカバリコマンドの実行が異常終了の場合にはS1100-11でNO、必要な隔離処理S1100-13を実行し、当該処理を含むコンテナアプリケーションコンテナあるいはシステムコンテナを隔離し、その旨を記録してS1100-07、当該処理は終了するS1100-14。その後、前記再構成処理を実行する。前記記載の手順は、図24に記載の基本動作をコマンドチェインとするように構成しても良い。これにより、前記スクリプトをアトミック操作として確実に実行できるようになる。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、下記のABCに記載の手段群を、当該手段群が前記ディペンダビリティ記述データを備えるシステムにおいて確実に実行されることを保証する手段を有していても良い。A障害対応サイクルP301において、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスの継続が不可能と判断された場合、変化対応サイクルP300において前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記障害対応サイクルP301において記録又は検出された情報から前記ディペンダビリティ記述データを備えるシステムのディペンダビリティ記述データの変更を前記変化対応サイクルP300に対する要求として当該変化対応サイクルP300に入力する手段。B前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、変化対応サイクルP300と障害対応サイクルP301との間での情報交換する手段。Cディペンダビリティ記述データから変換されたコンピュータで処理可能な形式のデータを、当該ディペンダビリティ記述データを備えるシステムが管理する手段を有することで、変化対応サイクルP300におけるステークホルダによる変更の要求の合意による結果を、確実に当該ディペンダビリティ記述データを備えるシステムに実施する手段。13.ノードへの実行可能プログラムの関連付け図32は、ディペンダビリティ記述データに関連付けられたプログラムの処理内容の一例を示すフローチャートである。図32に示すノード203-04は図6に示したものと同じノードである。当該ノードはキャッシュによるAppLogicの継続に関する。本実施の形態では、ディペンダビリティ記述データをランタイムコンピュータ102への組み込み手順に従って導入する。このとき、ディペンダビリティ記述データの各ノードには、ランタイムコンピュータ102のバイナリ実行部110Rで実行可能なプログラムを関連付けてもよい。また、モニタノードにも実行可能なプログラムが関連付けられて、ランタイムコンピュータ102に導入される。なお、ノードへのプログラムを関連付けは、外部参照情報104-04に記述できる。また、これらの処理について図32では当該プログラムの処理内容をフローチャートで表現したが、スクリプト言語を用いても良いし、バイナリ実行部110Rで直接実行可能なプログラムコードを用いても良い。プログラム1200には導入処理S1200-01と廃止処理S1200-11の2個の処理の手順が定義されている。導入処理S1200-01は実行権限の確認S1200-02後に、アプリケーションコンテナ提供部712図25の機能を利用してアプリケーションコンテナを生成S1200-03する。次に、AppLogic201-03図4bに対応するアプリケーションを読み込み、アプリケーション管理部714図25に当該プログラムコードを登録する。一方、廃止処理S1200-11は実行権限の確認S1200-12後に、AppLogic201-03に対応するアプリケーションを停止S1200-13し、アプリケーション管理部714から当該プログラムコードの登録を削除し、アプリケーションコンテナ提供部712の機能を利用して当該アプリケーションコンテナを削除する。図33は、ディペンダビリティ記述データに関連付けられたプログラムの処理内容の他の例を示すフローチャートである。図33に示すノード203-01は図7に示したものと同じノードである。当該ノードは多重型によるDBSの無停止に関する。すなわち、バックアップ系を有するデータベースシステムを、複数台を同時に稼働させる多重系のデータベースに関するディペンダビリティ記述データの一部であった。プログラム1201には更新処理S1201-01、導入処理S1201-11、廃止処理S1201-21の3個の処理の手順が定義されている。ディペンダビリティ記述データにおけるノードが置き換えられるとき、当該ノードにプログラムが関連つけられている場合には、そこに定義された更新処理を実行する。具体的には、図33では、ノード203-04をノード204-01で置き換えるので、ノードの更新処理が実行される。更新処理S1201-01の手順は、実行権限の確認S1201-01後に、置き換えられるノード図33の場合には図32のノード203-04に関連つけられた廃止処理S1200-11の手順を実行する。当該手順の実行に当たっては、図31のコマンド実行処理S1100のフローチャートに従い結果が記録S1201-04される。次に、導入処理S1201-11の手順は実行権限の確認S1201-12後に、システムコンテナ提供部702図25の機能を利用してシステムコンテナを作成する。次に、無停止DBSをインストールS1201-14し、アプリケーション管理部714図25に当該DBSを登録する。一方、廃止処理S1201-21の手順は実行権限の確認1201-21後に、無停止DBSを停止S1201-23し、アプリケーション管理部714から当該DBSの登録を削除S1201-24し、当該DBSのシステムコンテナをシステムコンテナ提供部702の機能を利用して削除S1201-25する。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、前記ディペンダビリティ記述データを備えるシステムが障害発生検出時および障害予兆検出時の障害対応サイクルP301を確実に実行するために、下記の手段群ABをコンピュータで処理するための表現手段を有していても良い。A上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを障害発生に際しても継続するように対処するプロセスにおいて、障害の発生を検出する手段モニタリング機能と、障害の発生した部分を隔離する手段隔離機能と、隔離された残りの部分でサービスを継続する手段と、障害の原因を検出する手段原因追及機能と、上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段継続性判断機能。B上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスにおいて、前記ディペンダビリティ記述データを備えるシステムの内部状態を記録する手段ロギングと、当該記録された内部状態から前記ディペンダビリティ記述データを備えるシステムの障害の予兆を検出する手段と、前記ディペンダビリティ記述データを備えるシステムの当該検出された障害に対応する部分を同定する手段と、当該検出された障害が上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段。また、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ランタイムコンピュータ102は、上記ディペンダビリティ記述データには上記再構成の手順が記載されており、上記再構成手段再構成部102-04は、上記ディペンダビリティ記述データに記載されている再構成の上記手順に従って、当該対象システムを再構成するように構成されても良い。これにより、ランタイムコンピュータ102は、ディペンダビリティ記述データに記載されている再構成の手順に従って、当該対象システムを再構成することができる。よって、再構成の手順をディペンダビリティ記述データの設計段階において、当該ディペンダビリティ記述データに記述しておくことができるため、再構成時に手順を作成する必要がない。14.合意形成ツールとの連携図34に、ディペンダビリティ記述データM1と、ソフトウェアSWに含まれるXML形式ディペンダビリティ記述データM2正確には、ディペンダビリティ記述データ内部表現M2であるが、ここでは、XML形式による内部表現を選択した場合について説明するので、XML形式ディペンダビリティ記述データM2と記す。と、ワークスペースコンピュータ101が備えるツール群の各機能との関係を示す。編集機能1300-01図1の編集ツール部101-02が備える機能は、ディペンダビリティ記述データM1を入力修正記録する。検証機能1300-02図1の検証ツール部101-01が備える機能は、当該ディペンダビリティ記述データM1の妥当性を検証する。ベンチマーク機能1300-03図1の検証ツール部101-01が備える機能は、当該ディペンダビリティ記述データM1におけるエビデンスを確認する。変換機能1300-04図1の編集ツール部101-02および開発ツール部101-04が備える機能は、差分検証モデルM1をソフトウェアSWへの組込形式である、XML形式ディペンダビリティ記述データM2に変換する。当該変換の際には、ディペンダビリティ記述データからモニタノード部分を抜き出し、その構造を維持しながら変換するように本実施例を構成しても良い。計測機能1300-05図1の検証ツール部101-01が備える機能は、当該XML形式ディペンダビリティ記述データM2のモニタノードにアクセスしてデータを計測抽出する。また、図35にベンチマーク機能図中ではDSBenchとして記載と図16に記載のDCaseEditorとの連携を示す。DCaseEditor上ではモニタノードに実行すべきベンチマークを指定できるように構成している。当該DCaseEditorからのベンチマーク実行指示に基づいて実際のベンチマークが実行され、その実行結果を反映することでエビデンスとして記録する。当該ベンチマーク結果はD値の算出に用いることができる。また、D値に影響のあるベンチマークを用意することも可能であり、その場合、D値への影響が大きいほどベンチマークの有効性も高いことになる。当該ベンチマークには、システムの性能に関する特性以外の、障害の原因になるような特性を検証するベンチマークが含まれていてもよい。このようなベンチマークの例としては、CPU負荷を変動させたときのシステムの振る舞いに関するベンチマーク、ネットワークの帯域幅を変動させたとき、または遅延を変動させたときのシステムの振る舞いに関するベンチマーク、余剰メモリを変動させたときのシステムの振る舞いに関するベンチマーク、過剰なアクセスをシミュレートすることでシステムに総合的に負荷をかけたときのシステムの振る舞いに関するベンチマーク、システムの構成コンポーネントを意図的に異常終了した際のシステムの振る舞いに関するベンチマーク、等が挙げられる。さらに、ディペンダビリティ記述データは、例えば図8に記載のDCase記述を用いた場合、当該記述の整合性や網羅性等の検証のために、Agda定理証明器httpwikiportalchalmersseagdapmwikiphpを用いるように構成しても良い。これにより、当該DCase記述の記述エラーを自動的に取り除くことが可能になる。なお、本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記変化対応サイクルP300におけるステークホルダ間での合意を形成するステップにおいて、ステークホルダからの要求の変更をコンピュータで処理可能な表現形式で記述する手段を有し、当該表現形式の論理的検証手段を有していても良い。15.ディペンダビリティ維持システム間の連携本実施の形態に係るディペンダビリティ維持システム100は、ワークスペースコンピュータ101、ディペンダビリティ記述データM1、ランタイムコンピュータ102から構成されると言える。そして、当該ディペンダビリティ維持システム100の計算可能なディペンダビリティは、当該ディペンダビリティ記述データM1が表現している。ここで、図36は、ディペンダビリティ維持システム100を2つ接続した構成例を示すブロック図である。図36に示すように、利用者のディペンダビリティ維持システム100Uに対してディペンダビリティ記述データに基づく機能を提供する提供者のディペンダビリティ維持システム100Sと、利用者の前記ディペンダビリティ維持システム100Uとを、ネットワーク1400-03で接続した複合システムが構成できる。ここで、図37は、図36に示した2つのディペンダビリティ維持システム100U,100Sを接続した構成における、独立した2つのディペンダビリティ維持システム100U,100S間での連携の一例を示す説明図である。提供者のディペンダビリティ維持システム100から、利用者のディペンダビリティ維持システム100Uに対して、SLAServiceLevelAgreementを含むSLAディペンダビリティ記述データM2-SLAが提示される。SLAディペンダビリティ記述データM2-SLAは、SLAの情報を含む以外は、ディペンダビリティ記述データ内部表現M2と同じである。SLAディペンダビリティ記述データM2-SLAに含まれるSLAには、ディペンダビリティ維持システム100Sにて公開されるインターフェースのディペンダビリティに関してのみ記述される。これは提供者が提示する情報であり、当該インターフェースに対しての提供者のディペンダビリティに関してのコミットメントとして捉えることができる。また、当該ディペンダビリティ記述データはD値を計算可能であり、利用者はD値を計算して提供者の公開インターフェースに関してのディペンダビリティが利用者の基準に合致するかを確認できる。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、2台以上の当該システムがネットワークによって相互接続された環境において、相互接続されていない環境において備えることが可能な上述した各手段を有していてもよい。16.サプライチェーン図38は、図1に示したディペンダビリティ維持システム100を2つ、本体側および部品側として統合した構成例を示すブロック図である。図38に示すように、機能の本体を実行する本体側のディペンダビリティ維持システム100Bに対して、前記機能の一部を部品側のディペンダビリティ維持システム100Pが部品として提供することが可能である。図38では、ディペンダビリティ記述データM-Bにおけるノードの1個1500-03が部品としての提供されている例を示す。部品側のディペンダビリティ維持システム100Pに示すディペンダビリティ記述データM-Pが、部品であるノード1500-03のディペンダビリティ記述データである。図39は、2つのディペンダビリティ維持システム100B,100Pを本体側および部品側として統合した構成における、独立した2つのディペンダビリティ維持システム100B,100P間での連携の一例を示す説明図である。本体側のディペンダビリティ維持システム100Bにおけるワークスペースコンピュータ101では、部品1500-03のディペンダビリティ記述データM-Pを検証するS1502-01。当該部品1500-03のディペンダビリティ記述データM-Pが妥当である場合には、本体側のディペンダビリティ維持システム100Bにおけるランタイムコンピュータ102で、当該部品1500-03のベンチマークを計測するS1502-02。その結果のエビデンスが十分であれば、本体側のディペンダビリティ維持システム100Bにおけるワークスペースコンピュータ101は当該部品1500-03を本体のディペンダビリティ記述データM-Bに統合するS1502-05。図40に、部品を統合する処理手順の詳細を示す。まず、当該部品1500-03のディペンダビリティ記述データM-Pを検証するS1502-01。次に、ベンチマークを実行してエビデンスを計測しS1502-02、さらに、D値を計算するS1502-03。その結果、D値が良好である場合には、統合可能でありS1502-04でYES、統合のための再構成を実行するS1502-05。一方、D値が満足できない場合にはS1502-04でNO、部品提供者に対して部品すなわち、そのディペンダビリティ記述データM-Pのアップデートを求めるS1502-06。以降、同様の手順を繰り返す。本発明のディペンダビリティ維持装置ディペンダビリティ維持システム100、ワークスペースコンピュータ101は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、当該システムが第3者の1又は複数のハードウェア又はソフトウェア部品で構成される場合において、各々の部品が前記ディペンダビリティ記述データを備え、当該システムのディペンダビリティ記述データとの互換性の検証手段を有していても良い。17.ディペンダビリティ記述データの表示図41を用いてランタイムコンピュータ102に格納されたディペンダビリティ記述データにおけるゴール群の一部が満足されなかった状況下で、ワークスペースコンピュータ101上の図16に記載のDCaseViewer260-07が当該状況を表示する例を示す。ここでは、満足されなくなったゴールがフラッシュ1600-01されており、必要に応じてオペレータにアテンションを求める1600-02。なお、図41はDCase記述例であるが、記載内容は本説明では重要ではなく、その構造のみを示す。最後に、ディペンダビリティ維持システム100の各ブロック、特にワークスペースコンピュータ101およびランタイムコンピュータ102の各ブロックは、ハードウェアロジックによって構成してもよいし、次のようにCPUを用いてソフトウェアによって実現してもよい。後者の場合、ディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102は、各機能を実現するプログラムの命令を実行するCPUcentralprocessingunit、上記プログラムを格納したROMreadonlymemory、上記プログラムを展開するRAMrandomaccessmemory、上記プログラムおよび各種データを格納するメモリ等の記憶装置記録媒体などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102の制御プログラムのプログラムコード実行形式プログラム、中間コードプログラム、ソースプログラムをコンピュータで読み取り可能に記録した記録媒体を、上記のディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102に供給し、そのコンピュータまたはCPUやMPUが記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー登録商標ディスク/ハードディスク等の磁気ディスクやCD-ROM/MO/MD/DVD/CD-R等の光ディスクを含むディスク系、ICカードメモリカードを含む/光カード等のカード系、あるいはマスクROM/EPROM/EEPROM/フラッシュROM等の半導体メモリ系などを用いることができる。また、上記のディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網virtualprivatenetwork、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth登録商標、80211無線、HDR、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。1本発明に係るディペンダビリティ維持装置は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置であって、対象システムのディペンダビリティに関するステークホルダ群によって合意された要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定手段と、を備えることを特徴としている。12また、本発明に係るディペンダビリティ維持装置の制御方法は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置の制御方法であって、対象システムのディペンダビリティに関するステークホルダ群によって合意された要求仕様を記述したディペンダビリティ記述データを取得する記述データ取得ステップと、上記記述データ取得ステップにて取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定ステップと、を含むことを特徴としている。上記の構成によれば、対象システムのディペンダビリティに関するステークホルダ群によって合意された要求仕様を記述したディペンダビリティ記述データに基づいて、対象システムのディペンダビリティの価値を定量的に示す評価値を求めることができる。それゆえ、対象システムのディペンダビリティの価値を定量的に表現できる。したがって、例えば、要求変更に伴ってディペンダビリティ記述データを変更するときや、対象システムの運用時に対象システムの状態を確認するときに、対象システムのディペンダビリティの価値を分かりやすく客観的に提示することができる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となるという効果を奏する。すなわち、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援することが可能となるという効果を奏する。2さらに、本発明に係るディペンダビリティ維持装置は、上記1に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データをステークホルダ群によって合意された要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルの少なくとも何れか一方を実行することを特徴としている。上記の構成によれば、さらに、変化対応サイクルおよび障害対応サイクルの少なくともいずれか一方において、対象システムのディペンダビリティの価値を示す評価値を求めることができる。したがって、例えば、変化対応サイクルにおいて、要求変更に伴ってディペンダビリティ記述データを変更するときに、評価値に基づいて、ディペンダビリティ記述データの変更案の適否を判断することが可能となる。また、例えば、障害対応サイクルにおいて、対象システムの運用時に対象システムの状態を、評価値に基づいて判断することが可能となる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となるという効果を奏する。3さらに、本発明に係るディペンダビリティ維持装置は、上記1に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データをステークホルダ群によって合意された要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記障害対応サイクルを実行するとともに、上記障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段を備えることを特徴としている。上記の構成によれば、さらに、障害対応サイクルを実行するディペンダビリティ維持装置において、対象システムの障害発生あるいは障害予兆を検知したとき、ディペンダビリティ記述データに基づいて、当該対象システムを再構成して、対象システムの運用を継続させることができるという効果を奏する。なお、対象システムの障害発生または障害予兆を上記評価値に基づいて検知してもよい。例えば、上記評価値が所定の変動許容範囲より悪化したとき、あるいは、上記評価値の時間変化の傾向が所定の基準より悪化したとき、障害発生を検出するようにしても良い。4さらに、本発明に係るディペンダビリティ維持装置は、上記3に記載の構成において、上記ディペンダビリティ記述データには上記再構成の手順が記載されており、上記再構成手段は、上記ディペンダビリティ記述データに記載されている再構成の上記手順に従って、当該対象システムを再構成することを特徴としている。上記の構成によれば、さらに、ディペンダビリティ維持装置は、ディペンダビリティ記述データに記載されている再構成の手順に従って、当該対象システムを再構成することができる。よって、再構成の手順をディペンダビリティ記述データの設計段階において、当該ディペンダビリティ記述データに記述しておくことができるため、再構成時に手順を作成する必要がないという効果を奏する。5さらに、本発明に係るディペンダビリティ維持装置は、上記3または4に記載の構成において、上記障害発生または障害予兆を検知し、上記対象システムの停止が不回避であるとき、上記変化対応サイクルを実行する装置に、上記ディペンダビリティ記述データの変更の要求を送信する変更要求送信手段を備えることを特徴としている。上記の構成によれば、さらに、障害対応サイクルを実行するディペンダビリティ維持装置において、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であると判断したとき、変化対応サイクルを実行する装置に、ディペンダビリティ記述データの変更の要求を送信することができる。なお、障害発生または障害予兆により、対象システムの停止が不回避であるか否かを、上記評価値に基づいて判断しても良い。一方、変化対応サイクルを実行する装置は、上記ディペンダビリティ維持装置が送信したディペンダビリティ記述データの変更の要求を受信したとき、当該要求に応じて、上記ディペンダビリティ記述データを変更する。したがって、障害対応サイクルを実行するディペンダビリティ維持装置と、変化対応サイクルを実行する装置とが連携して、障害対応サイクルにおいて、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であれば、変化対応サイクルにおいて、ディペンダビリティ記述データを変更するという、一連のプロセスを円滑に実行することができる。よって、オープン環境において、対象システムのディペンダビリティを継続的に維持することが可能となるという効果を奏する。6さらに、本発明に係るディペンダビリティ維持装置は、上記1に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データをステークホルダ群によって合意された要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記変化対応サイクルを実行するとともに、上記障害対応サイクルを実行する装置から、上記ディペンダビリティ記述データの変更の要求を受信したとき、上記ディペンダビリティ記述データを変更することを特徴としている。上記の構成によれば、さらに、変化対応サイクルを実行するディペンダビリティ維持装置において、障害対応サイクルを実行する装置から、ディペンダビリティ記述データの変更の要求を受信したとき、当該要求に応じて、上記ディペンダビリティ記述データを変更することができる。したがって、障害対応サイクルを実行する装置と、変化対応サイクルを実行するディペンダビリティ維持装置とが連携して、障害対応サイクルにおいて、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であれば、変化対応サイクルにおいて、ディペンダビリティ記述データを変更するという、一連のプロセスを円滑に実行することができる。よって、オープン環境において、対象システムのディペンダビリティを継続的に維持することが可能となるという効果を奏する。7さらに、本発明に係るディペンダビリティ維持装置は、上記1から6のいずれかに記載の構成において、上記ディペンダビリティ記述データは、互いに関連づけられたゴールノードとモニタノードとの組を規定するデータであり、上記ゴールノードは、ステークホルダ群によって合意された要求仕様がゴール形式にて記述されたノードであり、上記モニタノードは、上記ゴールノードに記述されたゴールが充足されていることを表明するエビデンスであるとともに、上記対象システムの監視点に対応付けられており、上記ディペンダビリティ値決定手段は、対応付けられた上記監視点から取得されたデータが変動許容範囲に対して良好であるモニタノードに基づいて、上記評価値を計算することを特徴としている。上記の構成によれば、さらに、互いに関連づけられたゴールノードとモニタノードとの組を規定するデータ、例えば、木構造あるいはグラフ構造のデータから、多次元ベクトル値として評価値を求めることができる。また、本発明に係るディペンダビリティ維持装置は、上記1から6のいずれかに記載の構成において、上記ディペンダビリティ記述データは、ゴールノードとモニタノードとを組にすることが可能であるとともに、当該組を1以上有する木構造あるいはグラフ構造を有するデータであって、上記ゴールノードは、ステークホルダ群によって合意された要求仕様がゴール形式にて記述することが可能なノードであり、上記モニタノードは、上記ゴールノードに記載のゴールが満たされていることを表明するエビデンスであり、さらに、上記モニタノードは、上記対象システム内部の対応した監視点からのデータ取得を可能にした上で、当該監視点データが変動許容範囲に対して良好であることを判断する手段を備えており、上記ディペンダビリティ値決定手段は、上記エビデンスが良好であるモニタノードを上記木構造あるいはグラフ構造において計算することで上記評価値とすることを特徴としている。また、上記ディペンダビリティ維持装置は、上記ディペンダビリティ記述データがノード間のエッジに重み付けが可能な木構造あるいはグラフ構造を有するデータであり、上記ディペンダビリティ値決定手段は、上記エッジに重み付けされた重みを要素とする多次元ベクトル値を上記評価値としてもよい。上記の構成によれば、さらに、木構造あるいはグラフ構造のエッジに重み付けされた重みを要素とする多次元ベクトル値を評価値として求めることができる。それゆえ、木構造あるいはグラフ構造に、エッジの重要性を加味した評価値が得られる。よって、評価値を確認することで、エッジに重み付けの変更がディペンダビリティに与える影響を評価することができるという効果を奏する。なお、ここで得られる評価値は多次元ベクトル値であるが、目的に応じた任意の変換手法によりスカラー値に変換できることはいうまでもない。8さらに、本発明に係るディペンダビリティ維持装置は、上記1から6のいずれかに記載の構成において、上記ディペンダビリティ値決定手段は、上記対象システムをモニタして取得されたモニタ値が変動許容範囲に対して良好であったエビデンスに基づいて、上記評価値を計算することを特徴としている。上記の構成によれば、さらに、対象システムをモニタして取得されたモニタ値が変動許容範囲基準値に対して良好であったエビデンスに基づいて、評価値を計算することができる。その計算方法としては、例えば、ディペンダビリティ記述データに含まれるエビデンスの総数総エビデンス数に対する、モニタ値が変動許容範囲基準値に対して良好なエビデンスの数有効エビデンス数の割合を評価値として計算することができる。それゆえ、エビデンスの状態に応じた評価値が得られる。エビデンスは要求変更に応じて変化するため、ここで得られる評価値も要求変更に応じて変化する。すなわち、評価値を確認することで、要求変更がディペンダビリティに与える影響を評価することができるという効果を奏する。9さらに、本発明に係るディペンダビリティ維持装置は、上記1に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データをステークホルダ群によって合意された要求仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記障害対応サイクルを実行するとともに、上記障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに含まれるスクリプトを実行するスクリプト処理手段を備え、上記スクリプトは上記対象システムを変動許容範囲の状態に回復させるシナリオを含むことを特徴としている。上記の構成によれば、さらに、障害発生または障害予兆を検知したとき、ディペンダビリティ記述データに含まれるスクリプトを実行することによって、対象システムを変動許容範囲の状態に回復させることができる。なお、上記スクリプトは、ステークホルダによって合意されていることが好ましい。また、上記スクリプトは、対象システムに組み込まれたスクリプトエンジンによって実行される。また、上記スクリプトは、対象システム内部で取得されているログから、対象システムの状態が変動許容範囲にあるかを判断してもよい。また、対象システムを変動許容範囲の状態に回復させるシナリオを実行する際、当該シナリオは、GUIを介してオペレータから操作を受け付けてもよい。10また、本発明に係るディペンダビリティ維持システムは、対象システムのディペンダビリティを維持するためのディペンダビリティ維持システムであって、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データをステークホルダ群によって合意された要求仕様の変更に合わせて変更する変化対応サイクルを実行するワークスペース装置と、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルを実行するランタイム装置とを含み、上記ワークスペース装置および上記ランタイム装置の少なくともいずれか一方が、上記ディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めることを特徴としている。11さらに、本発明に係るディペンダビリティ維持システムは、上記10に記載の構成において、他のディペンダビリティ維持システムとネットワークを介して接続されていることを特徴としている。なお、上記のディペンダビリティ維持装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記の各手段として動作させることにより上記ディペンダビリティ維持装置をコンピュータにて実現させるディペンダビリティ維持装置のプログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。実施の形態2本実施の形態に係るディペンダビリティ維持装置20は、要求仕様書およびシステムの更新の間の無矛盾性を維持することを容易にするものである。そのため、後述するように、本実施の形態に係るディペンダビリティ維持装置20は、監視制御対象システム2のディペンダビリティに関する仕様を記述したDCaseをDCase格納部10から読み出し、監視制御対象システム2の状態を監視し、必要な場合に対策を実行する障害監視制御部30の動作を制御する監視制御データを、上記読み出したDCaseから生成し、障害監視制御部30に供給するDCase変換部21を備える。以下、図42から図56、および図8に基づいて、本発明の一実施の形態について詳細に説明する。図42は、本実施の形態に係る障害対応システム1の構成の概略を示す機能ブロック図である。本実施の形態に係る障害対応システム1は、監視制御対象システム2の動作を監視し、障害を発生した場合に、必要な対応措置を行うものである。なお、監視制御対象システム2としては、任意のコンピュータシステムに適用可能であるが、特に、単一のシステムではなく、複数のステークホルダが存在する、高度で複雑なディペンダビリティが必要とされているシステムに好適である。具体的には、社会インフラシステムの基盤であるようなコンピュータシステム、例えば、監視システム、電子決済システム、交通航空管制システム、さらには、それらを包含するクラウドシステムに好適である。そして、特に、本実施の形態に係る障害対応システム1は、監視制御対象システム2の各ステークホルダの合意の記述を容易にするとともに、監視制御対象システム2の一部更新があった場合に、合意の記述と監視制御のための実装モジュールの間が無矛盾に更新されるように維持することを特徴とするものである。すなわち、障害対応システム1は、ディペンダビリティ記述データで表現された監視制御対象システム2のディペンダビリティに関わる仕様と、監視制御対象システム2を監視制御するためのモニタモジュールやアクションモジュールの制御との間を、無矛盾に開発更新することを可能とする。そのために、障害対応システム1は、ディペンダビリティ記述データとして、各ステークホルダの合意の記述を容易に行うことができるという特徴を持つDCaseを用いて、監視制御対象システム2のディペンダビリティを記述する。また、障害対応システム1は、DCaseのパターンDCaseパターンと監視制御対象システム2を監視制御するためのモニタモジュールおよびアクションモジュールとの対応を管理する。これにより、監視制御対象システム2の変更等に応じて、モニタモジュールやアクションモジュールが追加変更されても、ディペンダビリティ記述とモニタモジュールおよびアクションモジュールとの対応を維持することができる。DCase図8は、DCaseの基本構造を示す説明図である。また、図43は、DCaseの具体例を示す説明図である。なお、図43は、顔認識を用いた監視システムを監視制御対象システム2とした場合のDCaseである。上記の通り、本実施の形態では、監視制御対象システム2のディペンダビリティに関する仕様を記述するディペンダビリティ記述データとして、DCaseを使用する。DCaseとは、SafetyCaseという、主にイギリスで用いられている、システムの安全性を保証するために用いられる構造化されたドキュメントを元にしている。本明細書では、SafetyCaseを元にしたディペンダビリティ記述データをDCaseと称するものとする。DCaseによれば、可用性などの一般的なディペンダビリティ属性は、図43のようなシステムレベルの議論に詳細化される。DCaseは、監視制御対象システム2に関わる各ステークホルダが合意するための構造化されたドキュメントである。詳細には、図8に示すように、DCaseは、システムのディペンダビリティをトップゴールとして、それが満たされていることを木構造により詳細化していき、詳細化されたゴールに対してエビデンスを置いた木構造を有する。DCaseは、後述するようにXMLExtensibleMarkupLanguageによって記述することができる。ここで、図43中、Gを付したブロックがトップゴールである。トップゴールとは、対象システムに対して、ステークホルダ間で合意すべき命題を表す。例えば対象システムは、安全性規格Xで定義されているSafetyIntegrityLevel3を満たすなどである。SGを付したブロックがサブゴールである。サブゴールとは、トップゴールを示すために、示すべきことを分割した命題を表す。例えば、トップゴールがAである、かつ、Bであるであるとき、サブゴールAである、Bであるに分割する。サブゴールは、さらに小さなサブゴールに分割されうる。トップゴール、サブゴールを総称して、ゴールと呼ぶ。Stを付したブロックがストラテジである。ストラテジとは、ゴールが成り立つことを、そのサブゴール群によってどのように議論されるのかの補助説明を示す。例えば、ゴールがシステムは考えられる障害すべてに対応するであるとき、ストラテジとして、考えられる障害ごとに議論するをあげる。この場合、サブゴールは、システムは考えられる障害1に対応する、...、システムは考えられる障害Nに対応するとなる。Eを付したブロックがエビデンスである。エビデンスとは、分割され、詳細化されたゴールを、最終的に保証するリーフノードである。例えば、サブゴールSGシステムXのサブコンポーネントYは、障害Zに対処できるというゴールに対して、FTA解析結果というエビデンスをサブゴールSGの直下におく。サブゴールSGをさらにサブゴールに分割することも考えられるが、無限にゴールを分割することはできない。分割されたサブゴールを最終的に保証するものとして、エビデンスがおかれる。エビデンスの妥当性は,ステークホルダ間の合意に基づく。また、図47に示されるように、Cを付したブロックがコンテキストである。コンテキストは、ゴールやストラテジの内容を補足する情報を示す。例えば、ストラテジ考えられる障害ごとに議論するである場合、コンテキストとして考えられる障害のリストがそのストラテジに付けられうる。ストラテジやコンテキストは、DCaseを読むステークホルダが、ゴールの分割を追いながら読むときの助けとなる補助情報を示す。なお、ストラテジ、コンテキストは、木構造化するときには読みやすさのために記入するが、ランタイム時にはコメント扱いである。また、図50に示される、MonitorM1等のブロックがモニタである。モニタとは、システムが障害対応を行う際に必要になるランタイム時のシステムの情報を表す。例えば、ランタイム時のプロセスXのCPU使用率のモニタリングなどがモニタノードとなる。モニタはエビデンスのサブクラスである。障害対応システム1のモニタ管理部40により得られる情報をエビデンスとして用いる場合に、そのエビデンスをモニタノードとして表す。つづいて、図42および図44を参照しながら、上記障害対応システム1の構成および処理フローについて詳細に説明する。図42に示すように、障害対応システム1は、DCase格納部ディペンダビリティ記述格納部10、ディペンダビリティ維持装置20、障害監視制御部30、モニタ管理部40、モニタモジュール群50、アクション管理部60、アクションモジュール群70を備えて構成されている。上記DCase格納部10は、監視制御対象システム2についての、ステークホルダ間のディペンダビリティに関する合意を記述したディペンダビリティ記述データであるDCaseを格納する。なお、障害対応システム1では、各ステークホルダが合意したDCaseが入力となる。上記ディペンダビリティ維持装置20は、監視制御対象システム2を監視制御するための実装モジュールモニタモジュール、アクションモジュールの制御とDCaseパターンとの対応を示すDCaseパターンモジュール対応テーブル後述するを使用して、DCaseから監視制御データ障害対応スクリプトを生成する。そのために、ディペンダビリティ維持装置20は、DCase変換部ディペンダビリティ記述変換部21、対応テーブル格納部22を備えて構成されている。上記DCase変換部21は、障害監視制御部30の動作を制御する監視制御データ障害監視制御用データを、DCase格納部10に格納されているDCaseから生成する。ここで、DCaseは、その一部分がパターン化されている。そして、上記対応テーブル格納部22は、DCaseパターンと監視制御データとの対応を表わすテーブルDCaseパターンモジュール対応テーブルを格納している。DCase変換部21は、対応テーブル格納部22に格納されているDCaseパターンモジュール対応テーブルを参照して、DCaseから監視制御データを生成する。つぎに、上記障害監視制御部30は、監視制御対象システム2の状態を監視モニタし、必要な場合に対策アクションを実行する。具体的には、障害監視制御部30は、ディペンダビリティ維持装置20においてDCase変換部21が生成した監視制御データに従って、モニタ管理部40とアクション管理部60を制御する。監視制御データは、モニタ管理部40によるモニタモジュールモニタモジュール群50の選択および動作の制御、並びに、アクション管理部60によるアクションモジュールアクションモジュール群70の選択および制御を規定している。上記モニタ管理部40は、監視制御データに従って、1以上のモニタモジュールモニタモジュール群50を管理する。本実施の形態では、モニタモジュールの例として、CPU監視モジュール51、メモリ監視モジュール52を挙げるが、本発明はこれに限定されない。上記アクション管理部60は、監視制御データに従って、1以上のアクションモジュールアクションモジュール群70を管理する。本実施の形態では、アクションモジュールの例として、CPU制限モジュール71、メモリ制限モジュール72、プロセス死活モジュール73を挙げるが、本発明はこれに限定されない。図44は、障害対応システム1の処理を示すフローチャートである。まず、DCase管理者が、ステークホルダ間の合意のもとで作成、変更されたDCaseを、DCase格納部10に格納するS1;DCase格納ステップ。次に、DCase変換部21が、DCase格納部10からDCaseを読み出しS2;DCase読み出しステップ、読み出したDCaseから、対応テーブル格納部22に格納されているDCaseパターンモジュール対応テーブルを参照して、障害監視制御部30の動作を制御する監視制御データを生成するS3;DCase変換ステップ。なお、DCaseの変更に伴って監視制御データを生成する場合には、DCase変換部21は、変更されたDCaseの差分のみに対応する監視制御データを作成してもよい。次に、障害監視制御部30が、作成された監視制御データに従って、監視制御対象システム2の状態を監視モニタし、必要な場合に対策アクションを実行するS4;障害監視実行ステップ。ここで、上記障害監視実行ステップS4について説明する。まず、モニタ管理部40には、管理すべきモニタモジュールがあらかじめ制御可能に登録されている。また同様に、アクション管理部60には、管理すべきアクションモジュールがあらかじめ制御可能に登録されている。そして、障害監視実行ステップS4では、障害監視制御部30が、監視制御データに従ってモニタ管理部40に適切なモニタモジュールを起動するよう指示する。そして、障害監視制御部30は、モニタ管理部40から通知されたモニタモジュールの実行結果が条件を満たす場合、さらに、アクション管理部60に適切なアクションモジュールを起動して障害に対処するように指示する。このとき、モニタ管理部40およびアクション管理部60は、それぞれ、障害監視制御部30からの指示に従ってモジュールを起動し、適切な引数を渡す。DCase変換つぎに、図45~図49を参照しながら、DCaseから監視制御データへの変換処理について詳細に説明する。障害対応システム1では、DCaseから、監視制御対象システム2を監視制御するためのモニタモジュールおよびアクションモジュールの動作を制御する監視制御データへの変換に、DCaseパターンモジュール対応テーブルを用いる。ここで、DCaseパターンとは、監視制御対象システム2のDCaseの一部であり、可用性などが、システムレベルでどのように維持されるかを示すものである。すなわち、システムの可用性とは、システムが障害などでサービスを行えない状態になったときシステムダウン状態、できるだけ早急に復旧し、利用者がサービスを用いたい時にいつでも用いられるようにできるシステムの性質である。障害が発生した場合、保守管理者などの人員により迅速に行うこと、およびシステム自体が自動的に障害復旧機能により復旧を行う。一般にシステムは、OSレベルにおいては、CPU資源、メモリ資源、ネットワーク資源などを用いて、サービスを提供する。したがって、CPU資源などが不足した場合、サービスの遅延などが発生し、可用性が減じる可能性がある。よって、あるサービスに用いるCPU資源が減じた場合、他の重要度の低いサービスで用いられているCPU資源を転用するなどの対応をシステムはOSレベルで自動的に行う。監視制御対象システム2のDCaseは、上記観点から、システムレベルでの可用性について議論している。DCaseパターン図45は、DCaseパターンを含むDCaseの具体例を示す説明図である。DCaseパターンとは、DCaseの部分木であり、可変な部分を含むものである。図45はパターンの一例であり、プロセスの属性が適切に保たれることを表現する場合に使用される。サブゴールSG22とエビデンスE25、E26のの部分が可変変数であり、他は固定されたDCaseパターンである。図45は、内に既に画像処理、CPU使用率、50以下を代入した状態を示している。このDCaseパターンがDCaseの一部として使用される場合に、部分にはステークホルダ間の合意に基づく値が代入され、その代入される値により、モニタモジュールやアクションモジュールと適切に関連づけることが可能となる。また、他は固定されたDCaseである。DCaseパターン、すなわちDCaseの部分には、ステークホルダ間の合意に基づく値が代入される。また、DCaseの部分に値が代入されることにより、モニタモジュールやアクションモジュールと適切に関連づけることが可能となる。図46は、DCaseパターンモジュール対応テーブルの一例であって、aはモニタモジュールについての対応テーブルを示し、bはアクションモジュールについての対応テーブルを示す。図46aは、≪プロセス1の2が3であることをモニタする≫というDCaseを、DCase変換部21が変換するときに参照するテーブルである。このDCaseでは、1、2、3が変数である。例えば、図45のDCaseを処理する際、DCase変換部21は、エビデンスE25の記述≪プロセス画像処理のCPU仕様率が50以下であることをモニタする≫に当てはめることができるテーブル図46aを対応テーブル格納部22から読み出す。そして、エビデンスE25の記述から抽出した変数1、2、3の値を用いて、DCaseパターンとモジュールとの対応関係を特定し、監視制御データを作成する。具体的には、変数2がCPU仕様率であることから、モジュール名CPU監視および引数1、3を特定し、≪CPU監視モジュールを呼び出し、画像処理50以下を引数として渡す≫という内容の監視制御データを作成する。同様に、DCase変換部21は、エビデンスE26の記述≪プロセス画像処理のCPU仕様率を50以下に制限する≫に当てはめることができるテーブル図46bを対応テーブル格納部22から読み出す。そして、変数2がCPU仕様率であることから、モジュール名CPU制限および引数1、3を特定し、≪CPU制限モジュールを呼び出し、画像処理50以下を引数として渡す≫という内容の監視制御データを作成する。上記のように、エビデンスの記述のうち、固定されたDCaseの文字列記述の固定部分に応じて、DCaseパターンモジュール対応テーブルが選択される。そして、一部の変数上記の例では、変数2の値に応じて、対応するモジュールが選択される。このように、本実施の形態では、エビデンスの記述を一部に変数が設定された表現形式とし、そのエビデンスに則した値を変数に設定して、エビデンスを記述する。つぎに、図47、図48を参照して、図45のDCaseが変更された場合の処理について説明する。図47は、DCaseパターンを含むDCaseの具体例を示す説明図である。図47では、図45に対して、コンテキストC31が追加されるとともに、エビデンスE26がエビデンスE32に変更されている。これは、≪C31:他のプロセス顔認識を制限してでも画像処理にCPUを十分与えたい≫ため、≪E32:プロセス顔認識をkillする≫ことで、各ステークホルダが合意したことを示している。図48は、このときのDCaseパターンモジュール対応テーブルの一例である。図48aはモニタモジュールについての対応テーブルを示し、図48bはアクションモジュールについての対応テーブルを示す。図48aは、図46aと同じである。そして、図47のDCaseを処理する際、DCase変換部21は、エビデンスE32の記述≪プロセス顔認識をkillする≫に当てはめることができるテーブル図48bを対応テーブル格納部22から読み出す。そして、エビデンスE32の記述から抽出した変数1、2の値を用いて、DCaseパターンとモジュールとの対応関係を特定し、監視制御データを作成する。具体的には、変数2がKillであることから、モジュール名プロセス死活および引数1を特定し、≪プロセス死活モジュールを呼び出し、Kill顔認識を引数として渡す≫という内容の監視制御データを作成する。このように、DCaseパターンモジュール対応テーブルには、引数として、変数だけでなく、定数値を設定しておくこともできる。すなわち、図48bでは、変数2の値がKillであれば、プロセス死活モジュール73へ渡す1番目の引数はKillとなり、変数2の値がRestartであれば、渡す引数はRestartとなる。また、変数2の値がMigrationであれば、プロセス死活モジュール73ではなく、Migrationモジュール図示せずがアクションとして実行されることになる。つぎに、図49を参照して、新たにモニタモジュールやアクションモジュールを追加した場合の処理について説明する。新たにモニタモジュールやアクションモジュールを追加した場合には、モニタ管理部40やアクション管理部60に登録する前に、DCase管理者が、DCaseパターンモジュール対応テーブルに対応関係を規定するデータ変換規則を追加する。図49は、DCaseパターンモジュール対応テーブルの一例であって、モニタモジュールについての対応テーブルを示す。例えば、ネットワーク転送量を監視するモジュールを新たに追加した場合、図49のように、図46aに1行追加される。まとめ以上のように、上記障害対応システム1では、モニタ管理部40によるモニタモジュールの選択および動作の制御、並びに、アクション管理部60によるアクションモジュールの選択および制御と、DCaseパターンとの対応を示すDCaseパターンモジュール対応テーブルを使用して、DCaseから監視制御データを生成する。すなわち、DCase格納部10に格納されたDCaseは、DCaseパターンモジュール対応テーブルを参照しながら、障害監視制御部30の監視制御データに変換される。このように、障害監視制御部30が用いる監視制御データが、DCase部10に格納されたDCaseから、DCase変換部21によって生成されることにより、DCaseと障害監視制御部30の動作との間が常に無矛盾になるように維持される。また、DCase格納部10に格納されているDCaseを変更した場合、その変更はDCase変換部21によって監視制御データの変更として障害監視制御部30に通知される。なお、DCaseの変更をディペンダビリティ維持装置20あるいはDCase変換部21が検知し、変更後の監視制御データを障害監視制御部30に自動的に通知するようにしてもよい。また、DCase管理者は、DCaseに新たにDCaseパターンを追加した場合、DCaseパターンモジュール対応テーブルに対応関係を規定するデータ変換規則を追加する。また、モニタモジュールやアクションモジュールを修正追加した場合、障害対応システム1はDCase管理者に通知する。DCase管理者は、修正追加されたモニタモジュールやアクションモジュールに対応するDCaseパターンモジュール対応テーブルも合わせて修正する。なお、修正追加されたモニタモジュールやアクションモジュールに対応するDCaseパターンモジュール対応テーブルが修正されない場合、モニタモジュールあるいはアクションモジュールがDCaseと対応できてないので、監視制御データが使用できない。修正されたDCaseパターンモジュール対応テーブルを使用して監視制御データを修正することによって、DCaseと障害監視との間の無矛盾性が維持される。また、DCaseパターンモジュール対応テーブルは、データベースに蓄積しておき、DCaseを変更する際、適切なDCaseパターンモジュール対応テーブルを参照するように、データベースから抽出して利用するようにしてもよい。これにより、DCaseの変更の度にDCaseパターンモジュール対応テーブルを作成する必要がなくなり、低コストでDCaseの変更に対応することが可能となる。つづいて、図50~図56を参照しながら、他の具体例について説明する。図50および図51は、DCaseの他の具体例を示す説明図である。図50と図51は連結部Aで連結されて、一つの木構造となる。また、図52~図55は、図50、図51に示したDCaseをXML形式で記述した例を示す説明図である。なお、図52~図55には、図50、図51に示したDCaseから一部を抜粋して示している。図56は、図50、図51、および図52~図55に示したDCaseから変換した監視制御データ障害対応スクリプトの例を示す説明図である。図52~図55に示すように、本具体例では、DCaseのXMLファイルに障害監視制御部30を制御する障害対応スクリプトが埋めこまれている。そして、図56が、DCaseのXMLファイル図52~図55のMonitorM1~MonitorM5からそれぞれ抽出されたスクリプトである。なお、図50および図51は、図52~図55をグラフィカルに表示したものであり、データには障害対応スクリプトも含まれている。このように、DCaseに障害対応スクリプトが埋め込まれている点が、図45~図49を参照しながら説明した、DCaseパターンモジュール対応テーブル具体例とは異なっている。しかしながら、ステークホルダの合意を示すDCaseと、監視制御対象システムの障害対応スクリプトとの間を無矛盾に更新することができる点では同じである。本発明は以下のように構成してもよい。本発明のディペンダビリティ維持装置20は、監視制御対象システム2の状態を監視し、必要な場合に対策を実行する障害監視制御部30の動作を制御する障害監視制御用データ監視制御データを生成し、上記障害監視制御部30に供給するディペンダビリティ維持装置20であって、上記監視制御対象システム2のディペンダビリティに関する仕様を記述したディペンダビリティ記述データDCaseをディペンダビリティ記述格納部DCase格納部10から読み出し、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成するディペンダビリティ記述変換部DCase変換部21を備えて構成されていてもよい。また、本発明のディペンダビリティ維持装置20の制御方法は、監視制御対象システム2の状態を監視し、必要な場合に対策を実行する障害監視制御部30の動作を制御する障害監視制御用データを生成し、上記障害監視制御部30に供給するディペンダビリティ維持装置20の制御方法であって、上記監視制御対象システム2のディペンダビリティに関する仕様を記述したディペンダビリティ記述データDCaseをディペンダビリティ記述格納部DCase格納部10から読み出す読み出しステップS2と、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成する変換ステップS3とを含む方法であってもよい。さらに、上記ディペンダビリティ維持装置20は、上記障害監視制御部30は、上記監視制御対象システム2の状態を監視し、必要な場合に対策を実行するために使用するモジュールを、複数のモジュールモニタモジュール群50、アクションモジュール群70から選択して制御可能であり、上記ディペンダビリティ記述データは、1つの記述エビデンスが、上記モジュールを特定するためのモジュール特定情報変数2;パターンを値として設定可能な変数を少なくとも含む形式であり、上記ディペンダビリティ記述変換部は、あらかじめ設定された、上記モジュール特定情報と上記障害監視制御用データとの対応関係を示す情報DCaseパターンモジュール対応テーブルに基づいて、上記ディペンダビリティ記述データに含まれる変換対象の記述を、該記述に含まれるモジュール特定情報に対応する障害監視制御用データに変換するように構成されていてもよい。さらに、上記ディペンダビリティ維持装置20は、上記ディペンダビリティ記述データの1つの記述から変数部分を除いた固定部分に対応して、上記対応関係が設定されており、上記ディペンダビリティ記述変換部は、上記ディペンダビリティ記述データの記述に含まれる上記固定部分に対応する上記対応関係を参照して、該記述を対応する障害監視制御用データに変換するように構成されていてもよい。また、本発明の障害対応システム1は、上記のディペンダビリティ維持装置20と、上記ディペンダビリティ記述格納部DCase格納部10と、上記障害監視制御部30とを含み、上記ディペンダビリティ維持装置20が上記ディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから生成した障害監視制御用データに従って、上記障害監視制御部30が動作することにより、上記監視制御対象システム2の状態を監視し、必要な場合に対策を実行するように構成されていてもよい。さらに、上記障害対応システム1は、上記監視制御対象システム2の状態を監視する1以上のモニタモジュールモニタモジュール群50と、必要な場合に上記監視制御対象システム2に対して対策を実行する1以上のアクションモジュールアクションモジュール群70と、上記障害監視制御部30の制御により、上記モニタモジュールの選択および動作の制御を行うモニタ管理部40と、上記障害監視制御部30の制御により、上記アクションモジュールの選択および動作の制御を行うアクション管理部60と、を含んで構成されていてもよい。また、本発明は以下のように構成してもよい。本発明に係るコンピュータシステム障害対応システム1は、ステークホルダ間のディペンダビリティに関する合意を記述したディペンダビリティ記述データDCaseを格納するディペンダビリティ記述格納部DCase格納部10と、対象システム監視制御対象システム2内の状態を監視モニタし必要な場合に対策アクションを実行する障害監視制御部障害監視制御部30と、障害監視制御部の動作を制御する障害監視制御用データ監視制御データをディペンダビリティ記述データから生成するディペンダビリティ記述変換部DCase変換部21とを持ち、障害監視制御用データが常にディペンダビリティ記述格納部に格納されたディペンダビリティ記述データからディペンダビリティ記述変換部によって生成されることによりディペンダビリティ記述と障害監視制御部の動作とが無矛盾に維持されるように構成されていてもよい。さらに、上記コンピュータシステムは、ディペンダビリティ記述はその一部分がパターン化されており、ディペンダビリティ記述のパターンと障害監視制御用データの対応を表わすテーブルDCaseパターンモジュール対応テーブルを使用して障害監視制御用データをディペンダビリティ記述から生成するように構成されていてもよい。さらに、上記コンピュータシステムは、障害監視制御部はモニタ管理部モニタ管理部40とアクション管理部アクション管理部60を持ち、モニタ管理部は1以上のモニタモジュールモニタモジュール群50を管理し、アクション管理部は1以上のアクションモジュールアクションモジュール群70を管理し、モニタ管理部によるモニタモジュールの選択および動作の制御、並びに、アクション管理部によるアクションモジュールの選択および制御と、ディペンダビリティ記述のパターンとの対応を示すテーブルを使用して障害監視制御用データをディペンダビリティ記述から生成するように構成されていてもよい。さらに、上記コンピュータシステムの制御方法は、ステークホルダ間のディペンダビリティに関する合意を記述したディペンダビリティ記述データを格納するディペンダビリティ記述格納ステップDCase格納ステップS1と、障害監視制御部が対象システム内の状態を監視し必要な場合に対策を実行する障害監視制御ステップ障害監視実行ステップS3と、障害監視制御ステップの動作を制御する障害監視制御用データをディペンダビリティ記述から生成するディペンダビリティ記述変換ステップDCase読み出しステップS2、DCase変換ステップS3とを持ち、障害監視制御用データが常にディペンダビリティ記述格納ステップによって格納されたディペンダビリティ記述データからディペンダビリティ記述変換ステップによって生成されることによりディペンダビリティ記述と障害監視制御部の動作とが無矛盾に維持されるように構成されていてもよい。また、障害対応システム1の各ブロック、特にディペンダビリティ維持装置20のDCase変換部21は、ハードウェアロジックによって構成してもよいし、次のようにCPUを用いてソフトウェアによって実現してもよい。後者の場合、障害対応システム1は、各機能を実現するプログラムの命令を実行するCPUcentralprocessingunit、上記プログラムを格納したROMreadonlymemory、上記プログラムを展開するRAMrandomaccessmemory、上記プログラムおよび各種データを格納するメモリ等の記憶装置記録媒体などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである障害対応システム1あるいはディペンダビリティ維持装置20の制御プログラムのプログラムコード実行形式プログラム、中間コードプログラム、ソースプログラムをコンピュータで読み取り可能に記録した記録媒体を、上記の障害対応システム1あるいはディペンダビリティ維持装置20に供給し、そのコンピュータまたはCPUやMPUが記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー登録商標ディスク/ハードディスク等の磁気ディスクやCD-ROM/MO/MD/DVD/CD-R等の光ディスクを含むディスク系、ICカードメモリカードを含む/光カード等のカード系、あるいはマスクROM/EPROM/EEPROM/フラッシュROM等の半導体メモリ系などを用いることができる。また、上記の障害対応システム1あるいはディペンダビリティ維持装置20を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網virtualprivatenetwork、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth登録商標、80211無線、HDR、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。上記説明では、機能ブロックおよび手順を図示し参照したが、機能の分離併合または手順の移動は上記機能を満たす限り可能であり、上記説明が本発明を限定するものではない。1本発明に係るディペンダビリティ維持装置は、監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置であって、上記監視制御対象システムのディペンダビリティに関するステークホルダ群によって合意された要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出し、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成するディペンダビリティ記述変換部を備えたことを特徴としている。6また、本発明に係るディペンダビリティ維持装置の制御方法は、監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置の制御方法であって、上記監視制御対象システムのディペンダビリティに関するステークホルダ群によって合意された要求仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出す読み出しステップと、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成する変換ステップとを含むことを特徴としている。上記の構成によれば、ディペンダビリティ維持装置がディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから障害監視制御用データを生成する。そして、これに従って障害監視制御部が動作することにより、障害監視制御部が監視制御対象システムの状態を監視し、必要な場合に対策を実行することができる。ここで、ペンダビリティ記述データは、監視制御対象システムのディペンダビリティに関わる仕様を記述したものである。そして、監視制御対象システムの各ステークホルダが監視制御対象システムのディペンダビリティに関して合意した際、その結果がペンダビリティ記述データとして記述され、ディペンダビリティ記述格納部に格納されたものであることが望ましい。このように、障害監視制御部が用いる障害監視制御用データが、ディペンダビリティ記述格納部に格納されたディペンダビリティ記述データから、ディペンダビリティ維持装置によって生成されることにより、ディペンダビリティ記述データと障害監視制御部の動作とが常に無矛盾になるように維持することが可能となる。2さらに、本発明に係るディペンダビリティ維持装置は、上記1に記載の構成において、上記障害監視制御部は、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行するために使用するモジュールを、複数のモジュールから選択して制御可能であり、上記ディペンダビリティ記述データは、1つの記述が、上記モジュールを特定するためのモジュール特定情報を値として設定可能な変数を少なくとも含む形式であり、上記ディペンダビリティ記述変換部は、あらかじめ設定された、上記モジュール特定情報と上記障害監視制御用データとの対応関係を示す情報に基づいて、上記ディペンダビリティ記述データに含まれる変換対象の記述を、該記述に含まれるモジュール特定情報に対応する障害監視制御用データに変換することを特徴としている。上記の構成によれば、さらに、ディペンダビリティ記述データに含まれる変換対象の記述を障害監視制御用データに変換する際、該記述に含まれるモジュール特定情報によって特定されるモジュールを障害監視制御部に選択させ、制御させる障害監視制御用データを生成する。これにより、障害監視制御部が制御可能なモジュールが複数ある場合であっても、ディペンダビリティ記述データの記述から適切なモジュールを制御対象とした障害監視制御用データを生成することが可能となる。3さらに、本発明に係るディペンダビリティ維持装置は、上記2に記載の構成において、上記ディペンダビリティ記述データの1つの記述から変数部分を除いた固定部分に対応して、上記対応関係が設定されており、上記ディペンダビリティ記述変換部は、上記ディペンダビリティ記述データの記述に含まれる上記固定部分に対応する上記対応関係を参照して、該記述を対応する障害監視制御用データに変換することを特徴としている。上記の構成によれば、さらに、ディペンダビリティ記述データに含まれる変換対象の記述を障害監視制御用データに変換する際、該記述からに含まれる変数部分を除いた固定部分に対応した対応関係を参照して、該記述を対応する障害監視制御用データに変換する。これにより、ディペンダビリティ記述データに含まれる記述の固定部分毎に、異なる対応関係を対応付けておくことが可能となる。よって、モジュール特定情報等の変数が同じであっても、固定部分が異なれば、異なる対応関係を用いて、ディペンダビリティ記述データに含まれる記述を障害監視制御用データに変換することができる。それゆえ、多様な変換を簡易な規則によって実現することができる。4また、本発明に係る障害対応システムは、上記1から3のいずれかに記載のディペンダビリティ維持装置と、上記ディペンダビリティ記述格納部と、上記障害監視制御部とを含み、上記ディペンダビリティ維持装置が上記ディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから生成した障害監視制御用データに従って、上記障害監視制御部が動作することにより、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行するように構成してもよい。5さらに、本発明に係る障害対応システムは、上記4に記載の構成において、上記監視制御対象システムの状態を監視する1以上のモニタモジュールと、必要な場合に上記監視制御対象システムに対して対策を実行する1以上のアクションモジュールと、上記障害監視制御部の制御により、上記モニタモジュールの選択および動作の制御を行うモニタ管理部と、上記障害監視制御部の制御により、上記アクションモジュールの選択および動作の制御を行うアクション管理部と、を含むように構成してもよい。なお、上記のディペンダビリティ維持装置および障害対応システムは、コンピュータによって実現してもよく、この場合には、コンピュータを上記ディペンダビリティ記述変換部として動作させることにより上記ディペンダビリティ維持装置をコンピュータにて実現させるディペンダビリティ維持装置のプログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。上記説明では、機能ブロックおよび手順を図示し参照したが、機能の分離併合または手順の移動は上記機能を満たす限り可能であり、上記説明が本発明を限定するものではない。発明の詳細な説明の項においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求事項との範囲内で、いろいろと変更して実施することができるものである。"