Mercurial > hg > Papers > 2013 > nobuyasu-sigos
view paper/implmodel.tex @ 35:ba0d9639c2b5
modified conclution.tex
author | Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sun, 31 Mar 2013 09:17:09 +0900 |
parents | bd298748e806 |
children | 296354ad0003 |
line wrap: on
line source
\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} サーバサイドの実装は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}