\section{実装}
作成するアプリケーションのユースケース図を\figref{fig:usecase}に示す.
\begin{figure}[tb]
  \begin{center}
   \includegraphics[scale=0.30]{figure/usecase.pdf}
    \caption{ユースケース図}
    \label{fig:usecase}
  \end{center}
\end{figure}

まず, ユーザ(ステークホルダ)は主張を立てることができる.
この時, たてた主張は自分以外のユーザに対して合意要求を出さなければならない.
ユーザは自分に対して合意要求を出している主張を見ることができ, その合意要求に対して
合意・否認・保留のどれかを選択することができる.
また, 既にある主張に対して関係をはる主張を立てることができる.
ここでいう関係は反論・質問・提案のどれかである.

上記の操作で合意形成支援を行うWebアプリケーションを作成する.
また, 今回は合意がとられている様子がみられるよう, リアルタイムでデータが更新されていく
ものを作る.

\subsection{モデルの実装に使用するデータベース}
提案するモデルは木構造で議論を深めていく.
このことを念頭に, モデルの実装に使用するデータベースについて考えた.
結果, モデルの実装にはGraphDBを使用することにした.
なぜなら, 木構造は閉路を持たないグラフであり, GraphDBはグラフのデータの扱いが特異な
データベースだからである.

GraphDBはデータの情報をノードとエッジで持ち, ノードとエッジはそれぞれプロパティを持つことができる.
ノード同士はエッジで繋ぐこともでき, トラバースと呼ばれる操作でノード間を渡り歩き情報を
引き出すことができる.
また, エッジには関係が定義され, トラバースは渡り歩くエッジの関係を指定することで行える.

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

\subsection{GraphDBによるモデルの表現}
GraphDBを用いて提案したモデルを表現する.
提案するモデルの{\bf ユーザ}と{\bf 主張}がノードで, {\bf 関係}がエッジにあたる.
各主張とユーザとの関係を示したものが\figref{fig:tomodel0}となる.四角がノードを, 矢印がエッジをそれぞれ表している.

\begin{figure}[tb]
  \begin{center}
    \includegraphics[scale=0.35]{figure/TOModel0_2.pdf}
    \caption{主張ノードとユーザノードの繋がり}
    \label{fig:tomodel0}
  \end{center}
\end{figure}

今回使用したGraphDBはTinkerPopになる.
TinkerPopで実際にノードとエッジを作成するコードの例を示す.
\begin{lstlisting}
Graph g = new TinkerGraph();
Vertex claim = g.addVertex(ID);
Edge relation = g.addEdge(ID,From,To,Label);
claim.setProperty(PropertyName,PropertyValue);
\end{lstlisting}

1行目はグラフの作成を行っている.
引数にパスをいれると, パスにデータが保存される.
2行目ではノードの作成を行なっている.
引数には設定したいIDを引数に取る.
3行目では関係(エッジ)の作成を行なっている.
設定したいIDを引数に取る.
引数のFromとToはそれぞれノードで, FromからTo向きへのエッジが作成される.
4行目ではプロパティの作成を行っている.
ノード・エッジともに同様のメソッドでプロパティの作成ができる.

このようにノードとエッジ, それとプロパティの作成を行なっていく.
\figref{fig:tomodel0}において主張2,3からユーザへのエッジは省略しているが、
各主張ノードからはそれぞれ作者と合意要求の関係となるエッジがユーザノードへと繋げられる.




\subsection{実装内容}
サーバサイドの実装はJavaを使用した.
GraphDBはTinkerPop使用し, play frameworkによりREST APIを提供する.
クライアントサイドはJavaScript/HTML/CSSを用いる.
クライントサイドはサーバサイドが提供するREST APIを非同期に叩いて主にJSONデータを受け取り, ブラウザへと表示をおこなう.
実装の概略を\figref{fig:arch}に示す.

\begin{figure}[tb]
  \begin{center}
   \includegraphics[scale=0.30]{figure/architecture.pdf}
    \caption{Webアプリ実装概要}
    \label{fig:arch}
  \end{center}
\end{figure}

\subsection{各ノード, エッジのプロパティ}
ユーザノードは特にプロパティを持たないが, 主張ノードは以下のプロパティを持つ.
\begin{itemize}
  \item status : 主張の合意状態を表す. passed, failed, unknown の状態がある
  \item title : 主張のタイトル
  \item content : 主張の内容
  \item toulmin : トゥールミンモデルにおける主張以外の5つの要素が入る
  \item timestamp : 作成された時間を示すタイムスタンプ
\end{itemize}
主張のそれぞれの合意状態は, passedは合意されている, failedは否認された, unknownはpassedでもfailedでも無いことを示す.

主張同士を繋ぐエッジはプロパティを持たないが, ユーザへと伸びる合意要求のエッジだけは
以下のプロパティを持つ.
\begin{itemize}
\item status : ユーザの主張に対する合意状態を表す. agreed, denied, pend, unknown の状態がある.
\end{itemize}
agreedは合意, deniedは否認, pendは保留, unknownは最初の状態をそれぞれ示す.

\subsection{合意状態の計算}
基本, 各主張は自身に繋がっている合意要求の関係にあるエッジのstatusが全てagreedかfailedとなることで合意か否認されたとみなされる.
しかし, 今回のモデルの特徴の1つとしてエッジの関係により合意状態の計算が変わってくるというのがある.
これにより, ユーザへと伸びる合意要求のエッジの他に, 子となる主張の合意状態とエッジの関係も見る必要がでてくる.
主張が合意状態となるために以下の2つもチェックする必要がある.
\begin{itemize}
\item 反論の関係で繋がっている子の主張は全て否認の状態になってなければならない.
\item 質問の関係で繋がっている子の主張は全て合意の状態になってなければならない.
\end{itemize}
提案の関係は, 合意状態に影響を及ぼさないため気にする必要はない.


\subsection{時系列ごとにみられる合意状況}
合意形成を行う最中に, 一度否認された主張が合意されたり, 合意されていた主張が別の主張の登場で
否認されるといったことも起きることが考えられた.
この場合, 合意状態の時間的な変化も見ることより説明責任を果たすことの手助けになるのではないかと思われた.
そこでタイムスタンプをノードのプロパティとして新たに追加し, 更に主張同士の繋がりでできる木構造
のデータのコピーを行うことにした.
コピーされた木は最新の木に対してprevの関係となるエッジで繋げる.
これにより, prevエッジを辿ることで前の合意状態を見ることができるようになった(\figref{fig:temporal}).

\begin{figure}[tb]
  \begin{center}
   \includegraphics[scale=0.30]{figure/temporal.pdf}
    \caption{時系列毎の合意状態の保存}
    \label{fig:temporal}
  \end{center}
\end{figure}