\section{実装}
作成するアプリケーションのユースケース図を\figref{fig:usecase}に示す.
\begin{figure}[htpb]
  \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}となる.四角がノードを, 矢印がエッジをそれぞれ表している.
主張2,3からユーザへのエッジは省略しているが, 各主張ノードから
はそれぞれ作者と合意要求の関係となるエッジがユーザノードへと繋げられる.
%\figref{fig:tomodel0}において主張2,3からユーザへのエッジは省略しているが、
%各主張ノードからはそれぞれ作者と合意要求の関係となるエッジがユーザノードへと繋げられる.
\begin{figure}[htpb]
  \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向きへエッジが作成される.
Labelには関係の名前がはいる.
4行目ではプロパティの作成を行っている.
ノード・エッジともに同様のメソッドでプロパティの作成ができる.

このようにノードとエッジ, それとプロパティの作成を行い実装していく.

\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}[htpb]
  \begin{center}
   \includegraphics[scale=0.30]{figure/temporal.pdf}
    \caption{時系列毎の合意状態の保存}
    \label{fig:temporal}
  \end{center}
\end{figure}