ディペンダブルシステムのための木構造を用いた合意形成データベースの提案と実装
琉球大学 大城信康
26 April 2013
研究の背景と目的
- ITシステムが巨大化していくにつれ、障害発生時例が社会に与える影響もより大きな物となる。
- それに伴い、ITシステムにおけるディペンダビリティへの注目が増している。
- そこでDEOSプロジェクトはITシステムにおけるディペンダビリティを担保する技術体系をまとめ、制度化、更には事業化を目指している。
- DEOSプロジェクトは、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供するシステム構築法の開発を 目標としている。
- DEOSプロジェクトではそれらの技術体系を「オープンシステムディペンダビリティ」として定義し、それをDEOSプロセスとしてまとめた。
研究の背景と目的
- DEOSプロセスにおいて、全てのデータを保持するD-ADDと呼ばれるデータベースがある。
- D-ADDで扱うデータにはステークホルダ間で合意された契約書も含まれる。そのため、D-ADDに基本ツールとして合意形成支援ツールが必要である。
- 本研究では、D-ADDで行われる合意形成のモデルを提案しツールのプロトタイプの実装を行う。
- また、実際に例題の入力を行い、D-ADDにおける合意形成のあり方についての追求を行う。
DEOSプロセス
- DEOS(Dependability Engineering for Open Systems)
- 変化対応プロセス：ステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクル
- 障害対応サイクル：障害に対して迅速に対応して障害による被害を最小化するためのサイクル
- D-ADDにはDEOSプロセスで扱うデータがはいる
D-ADD(DEOS Agreement Description Database)
- D-ADDはステークホルダ合意と対象のシステムに依存するプログラム・コード、 及び対象システムの運用状態との間の一貫性を常に保つための機構を提供する。
- 基本ツール層：D-ADDにおける基本ツール
- モデル層：基本ツール層で扱うデータのモデルの定義
- リポジトリ層：D-ADDで扱うデータベース
D-ADD 説明責任と合意形成
- システム障害発生時、D-ADDは説明責任を果たさなければならない
- 説明責任：障害が発生した理由、次から障害を起こさせないことを説明する責任
- 「なぜそのようなシステムになったのか」を説明しなければならない
- そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべきである
- そこでD-ADD自身に合意形成を行う機能が必要となってくる
- 合意形成を行うシステムをWebアプリケーションとして提供する
モデルの提案
- 合意を取るためのモデルを提案する
- 提案するモデル
- 合意形成を主張・関係・ユーザの要素から構成される木と考える.
- まず命題となる合意を取りたい主張があり、それに対する別の主張を立てることで議論を深めていく
- 主張同士には関係が張られ、最初に作られた主張を根とし木構造で議論が深められていく
モデルの概要
- 木構造には閉路が含まれないため、循環論法を生じさせないという狙いがある
- ユーザ・主張・関係は以下のように定義される
- ユーザ：合意形成の参加者
- 主張：ユーザが作成した合意をとりたい、議論すべき内容を含むもの
- 関係：ユーザと主張、もしくは互いに異なる主張と主張の繋がりの種類を表す
- ユーザと主張はノード、関係はエッジとして扱われる
合意状態の計算
- 提案するモデルにおいて主張を合意させるには、合意要求を出している全員から合意を受ける必要がある
- 子となる主張がある場合、関係次第では子となる主張の合意状態も親の主張の合意状態に影響を与える
- 各関係の主張が与える合意状態への影響についての説明は以下となる
- 反論：反論となる子の主張が合意された場合親の主張は合意されない。反論の主張は否認しなければならない。
- 質問：質問となる主張は合意しなければならない。
- 提案：提案となる主張はどの状態であろうと親の合意状態に影響を与えない。
合意状態の計算
- 木構造で議論を表した例
- 根となる主張があり、反論となる主張と質問となる主張と繋がっている
- 根の主張の合意を取るため、反論で繋がっている主張は否認の状態であり、質問は合意の状態となっている
主張のモデル
- D-ADDでの合意形成支援は、議論だけでなく主張単体ののモデルについても考える。
- 議論のモデルとは別に主張単体のモデルについても考える
- 今回はトゥールミンモデルを内包した
- トゥールミンモデルだけでなく、他の主張モデルも使えるように考えていくつもりである。
Webアプリケーションの実装
- Webアプリケーションのユースケース図
Webアプリケーションの実装
- サーバサイドの実装はJavaを使用した
- クライアントサイドはJavaScript,HTML,CSSで実装を行った
- サーバサイドがREST APIを用意し、主にJSONデータを用いてデータのやりとりを行う
モデルの実装に使用するデータベース
- 議論は木構造で表される。木構造は閉路の無いグラフである
- そこで今回モデルの実装にGraphDBのTinkerGraphを使用する
- GraphDBはノードとエッジによりグラフでデータを表現する
- ノード、エッジともにプロパティを持つことができ、プロパティはkey,valueでデータを保持する
- エッジにはLabelが付けられ、また向き(Direction)がある。
- ノードは自身に繋がっているエッジをLabelとDirectionで指定することで次のノードの情報を得る。 この動作を走査(Traverse)という
GraphDBによるモデルの表現
- 主張、ユーザをノードで表し、関係をエッジで表す
- 「作者」や「合意要求」もエッジで表す
各ノードのプロパティ
- ユーザノードは特にプロパティは持たない
- 主張ノードは以下のプロパティを持つ
- status：主張の合意状態を表す。 passed, failed, unknown の状態がある
- title：主張のタイトル
- content：主張の内容
- toulmin：トゥールミンモデルにおける主張以外の5つの要素が入る
- timestamp：作成された時間を示すタイムスタンプ
- passedは合意されている、failedは否認された、unknownはどちらでも無いという合意状態を表す
エッジのプロパティ
- 主張同士を繋ぐエッジはプロパティを持たない
- ユーザへ伸びる合意要求のエッジが以下のプロパティを持つ
- status：ユーザの主張に対する合意状態を表す。agreed, pend, unknownの状態がある
- 基本、各主張は自身に繋がっている合意要求の関係にあるエッジのstatusが全てagreedかfailedとなる ことで合意か否認にされたとみなされる
合意状態の計算
- 合意状態に影響を与える子の主張がある場合の計算
- 以下の2点
- 反論の関係で繋がっている子の主張は全て否認の状態になっていなければならない
- 質問の関係で繋がっている子の主張は全て合意の状態になっていなければならない
- 提案の関係は、合意状態に影響を及ぼさないため考慮する必要はない
時系列ごとにみられる議論と合意状態
- 合意形成が行われる様子を時系列でみたい
- そこで、木のコピーを行い過去の合意状態を見ることができるようにする
- 木全体のコピーを行い、prevの関係になるエッジで繋げる
- prevをたどることで以前の合意状態と木を見ることができ、議論の流れを知ることができる
デモ
- デモ 合意形成支援Webアプリケーション
- ユーザ名：Akifumiでログイン
redmineとの比較
- redmineと合意形成支援Webアプリケーションの表示を比べる
- redmineではチケットと呼ばれる単位でプロジェクトの管理が行われる
redmineでの表示
- 親チケットのbldsvをリフレッシュする、と子チケットのセカンダリDNSサーバをたてる、の繋がりがわかりづらい
合意形成支援Webアプリケーションでの表示
- 各チケット(主張)のつながりが分かりやすい
時系列にみることの有用性
- 議論を行ううちに、一度は合意されたが否認され、また合意されるとった主張がでてくるかもしれない
- そのような場合は最新の合意状態をみるだけでは確認できない
- 時系列にみることができれば、その議論の流れを知ることができる
- これにより説明責任に使う情報を増やすことができる
| 最新 | 1つ前 | 2つ前 |
|
|
|
|
まとめ
- 議論のモデルを考えWebアプリケーションとして合意形成支援ツールの実装を行い D-ADDにおける合意形成支援についての追求を行った
- 木構造のモデルの提案とGraphDBを用いた実装を行った
- 実際に作成したWebアプリケーションにデータを入力し、redmineに入力した場合と比較した
- redmineで入力した場合に比べ、各主張同士の関係がみやすいことを確認した
- 時系列的に流れをみることで、合意までの議論の流れがより分かりやすくなり、合意全体の 理解を支援できる可能性を見ることができた
今後の課題
- 議論の木構造が巨大になった際の対処も考えなければならない
- 内容が同じ主張の検知を行っていない。検知をしてマージを行うなり、何かしら解決する機能を考える必要がある
- 同時に、マージが行われた主張が及ぼす影響をより分かりやすくみせることも理想である
- さらに、本実装では主張同士の関係に反論・質問・提案だけであったが、更に増やすことが可能である
- 関係を増やす場合は反論・質問・提案のを元に合意状態へと影響を与える主張を作成する
- どのような関係があればより合意形成支援を行うことができるのか考え行くべきである