\section{D-ADD}
D-ADDはステークホルダ合意と対象システムに存在するプログラム・コード, 及び対象システムの
運用状態との間の一貫性を常に保つための機構を提供する.\cite{d_add2012}
D-ADDの概略を\figref{fig:d-add}に示す.
上位層はD-ADDにおける基本ツールである. 
ここではDEOSプロセスとのやり取りを支援する.
2つめの層はD-ADDが扱うデータのモデルを指す.
今回提案するモデル含め, 上位層で扱うデータはここで定義される.
下位層はD-ADDで扱うデータベースである.
D-ADDは様々なデータを扱うため数種類のデータベスースを利用する予定である.

\begin{figure}[tb]
  \begin{center}
    \includegraphics[scale=0.35]{figure/d_add.pdf}
    \caption{D-ADD 概略}
    \label{fig:d-add}
  \end{center}
\end{figure}


\subsection{説明責任と合意形成}
D-ADDは障害が発生した際, 説明責任を果たさなければならない.
説明責任とはなぜその障害が発生したのか, 次からはその障害を起こさせない, もしくはしっかりと対応できることを示すことである.
そして説明責任を果たすためにはまず, なぜそのようなシステムになったのかと言うことを
説明できなければならないと考えられた.
そのためにはD-ADDに入るデータはプロジェクトに関わる人, ステークホルダの合意を得たデータ
にすべきである.
そこでD-ADD自身に合意形成を支援する機能が必要となってくる.
D-ADDはその合意形成支援をWebアプリケーションにより行う.

\subsection{KLのモデルを参考にした合意形成支援}
合意形成の実装の仕組みを考えるにあたり, D-ADD研究チーム所属の株式会社Symphonyが開発したKnowledge Line(以下KL)のモデルを参考にした.
KLは企業で使う情報インフラで, 企業内・企業間で情報の共有を行うWebアプリケーションである.
合意形成支援も行うことができる.
KLはPMT構造と呼ばれるモデルを使っている. 
Pはプロジェクト, Mはミッション, Tはタスクを表す.
Pの下にはいくつかのMを作ることができ, Mの下にはいくつかのTをつなげる階層構造となっている.
このPMT構造はRDBを使って実装されているが, 内部ではグラフ構造のようなものになっている.

PMT構造の実体がグラフ構造に近くなったという経験から, 今回の合意形成支援はグラフ構造のままデータを保存するGraphDBを用いることにした.

\subsection{GraphDB}
GraphDBはノードとエッジにより表されるグラフ構造であるデータの扱いが得意なデータベースである.
データの情報をノードとエッジで持ち, ノードとエッジはそれぞれプロパティを持つことができる.
ノード同士はエッジで繋がれ, トラバースと呼ばれる操作でノード間を渡り歩き情報を
引き出すことができる.
エッジには関係があり, トラバースは渡り歩くエッジの関係を指定することで行える.

GraphDBは各ノードが自身に繋がっているエッジの情報を保持しているため次のノードへと
渡り歩くことが容易である.
しかしRDBでこれを表そうとするとindexを引いてエッジの情報をとってきて次のノードの情報をとるという
手間がかかる.GraphDBを用いることでその手間のなくすことを狙いとする.

次は, 合意形成支援を行うに辺り提案したモデルを説明する.