ディペンダブルシステムのための木構造を用いた合意形成データベースの提案と実装
琉球大学 大城信康
26 April 2013
研究の目的と背景
- ITシステムが巨大化していくにつれ、障害発生時例が社会に与える影響もより大きな物となる。
- それに伴い、ITシステムにおけるディペンダビリティへの注目が増している。
- そこでDEOSプロジェクトはITシステムにおけるディペンダビリティを担保する技術体系をまとめ、制度化、更には事業化を目指している。
- DEOSプロジェクトは、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供するシステム構築法の開発を
目標としている。
- DEOSプロジェクトではそれらの技術体系を「オープンシステムディペンダビリティ」として定義し、それをDEOSプロセスとしてまとめた。
研究の目的と背景
- DEOSプロセスにおいて、全てのデータを保持するD-ADDと呼ばれるデータベースがある。
- D-ADDで扱うデータにはステークホルダ間で合意された契約書も含まれる。そのため、D-ADDに基本ツールとして合意形成支援ツールが必要である。
- 本研究では、D-ADDで行われる合意形成のモデルを提案しツールのプロトタイプの実装を行う。
- また、実際に例題の入力を行い、D-ADDにおける合意形成のあり方についての追求を行う。
D-ADD(DEOS Agreement Description Database)
- D-ADDはステークホルダ合意と対象のシステムに依存するプログラム・コード、
及び対象システムの運用状態との間の一貫性を常に保つための機構を提供する。
- 基本ツール層:D-ADDにおける基本ツール
- モデル層:基本ツール層で扱うデータのモデルの定義
- リポジトリ層:D-ADDで扱うデータベース
D-ADD 説明責任と合意形成
- システム障害発生時、D-ADDは説明責任を果たさなければならない
- 説明責任:障害が発生した理由、次から障害を起こさせないことを説明する責任
- 「なぜそのようなシステムになったのか」を説明しなければならない
- そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべきである
- そこでD-ADD自身に合意形成を行う機能が必要となってくる
- 合意形成を行うシステムをWebアプリケーションとして提供する
モデルの提案
- 合意を取るためのモデルを提案する
- 提案するモデル
- 合意形成を主張・関係・ユーザの要素から構成される木と考える.
- まず命題となる合意を取りたい主張があり、それに対する別の主張を立てることで議論を深めていく
- 主張同士には関係が張られ、最初に作られた主張を根とし木構造で議論が深められていく
モデルの概要
- 木構造には閉路が含まれないため、循環論法を生じさせないという狙いがある
- また、ユーザ・主張・関係は以下のように定義される
- ユーザ:合意形成の参加者
- 主張:ユーザが作成した合意をとりたい、議論すべき内容を含むもの
- 関係:ユーザと主張、もしくは互いに異なる主張と主張の繋がりの種類を表す
- ユーザと主張はノード、関係はエッジとして扱われる
合意状況の計算
- 提案するモデルにおいて主張を合意させるには、合意要求を出している全員から合意を受ける必要がある
- 子となる主張がある場合、関係次第では子となる主張の合意状況も親の主張の合意状況に影響を与える
- 各関係の主張が与える合意状況への影響についての説明は以下となる
- 反論:反論となる子の主張が合意された場合親の主張は合意されない。反論の主張は否認しなければならない。
- 質問:質問となる主張は合意しなければならない。
- 提案:提案となる主張はどの状況であろうと親の合意状況に影響を与えない。
合意状況の計算
- 木構造で議論を表した例
- 根となる主張があり、反論となる主張と質問となる主張と繋がっている
- 根の主張の合意を取るため、反論で繋がっている主張は否認の状態であり、質問は合意の状態となっている
主張のモデル
- D-ADDでの合意形成支援は、議論だけでなく主張単体ののモデルについても考える。
- 議論のモデルとは別に主張単体のモデルについても考える
- 今回はトゥールミンモデルを内包した
- トゥールミンモデルだけでなく、他の主張モデルも使えるように考えていくつもりである。
実装
- アプリケーションの実装に入る
- ユースケース図
モデルの実装に使用するデータベース
- 議論は木構造で表される。木構造は閉路の無いグラフである
- そこで今回モデルの実装にGraphDBのTinkerGraphを使用する
- GraphDBはノードとエッジによりグラフでデータを表現する
- ノード、エッジともにプロパティを持つことができ、プロパティはkey,valueでデータを保持する
- エッジにはLabelが付けられ、また向き(Direction)がある。
- ノードは自身に繋がっているエッジをLabelとDirectionで指定することで次のノードの情報を得る。
この動作を走査(Traverse)という
GraphDBによるモデルの表現