Mercurial > hg > Papers > 2013 > nobuyasu-sigos

view presen/index.html @ 85:6f6e4ab22c1b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
modified slide
author Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp>
date Fri, 26 Apr 2013 01:14:53 +0900
parents 5ad6483b895d
children 8a9685037126
line wrap: on
line source

<!DOCTYPE html>
<html>
  <head>
      <script type="text/javascript" src="js/jquery-1.9.1.min.js"></script>
    <style type="text/css">
      .center {
      margin-left: auto;
      margin-right: auto;
      text-align: center;
      }
    </style>

    <title>Presentation</title>

    <meta charset='utf-8'>
    <script
       src='./slides.js'></script>
  </head>
  
  <style>
    /* Your individual styles here, or just use inline styles if that’s
    what you want. */
    
    
  </style>

  <body style='display: none'>

    <section class='slides layout-regular template-default'>
      
      <!-- Your slides (<article>s) go here. Delete or comment out the
	   slides below. -->
      
      
      <article>
	<h3><font size=8em>
ディペンダブルシステムのための木構造を用いた合意形成データベースの提案と実装
	  </font>
	</h3>
	    <p class="center">
		<img src="./pic/compare_sample.png" style="width:50%;">
	    </p>
	<p>
	  琉球大学 大城信康
	  <br>
	 26 April 2013
	</p>
      </article>

      <article>
	  <h3>DEOSプロジェクト</h3>
	  <ul>
	      <li>ITシステムが巨大化していくにつれ、障害発生時例が社会に与える影響は大きい</li>
	      <li>DEOSプロジェクトはITシステムにおけるディペンダビリティを担保する技術体系をまとめ、制度化、更には事業化を目指しているCRESTのプロジェクト</li>
	      <li>変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供するシステム構築法、DEOSプロセスの開発を目標</li>
	  </ul>
      </article>

      <article>
	  <h3>DEOS(Dependability Engineering for Open Systems)</h3>
	  <ul>
	      <p class="center">
		  <img src="./pic/deos_proccess.png" style="width:70%;">
	      </p>
	      <li>変化対応サイクル：ステークホルダ間で決定されたサービスの運用に関する取り決め等に対応</li>
	      <li>障害対応サイクル：変化対応サイクルで決められた通りにサービスを稼働。障害に対して未然回避・迅速対応・原因追求
	      も行う</li>
	  </ul>
      </article>

      <article>
	  <h3>DEOSプロセスとD-ADD</h3>
	  <ul>
	      <li>D-ADDはDEOSプロセスで扱われるデータ、システムのログ、ソースコードといったものを保持するデータベース</li>
	      <li>D-ADDで扱うデータにはステークホルダ間で合意された契約書も含まれる。そのため、D-ADDに基本ツールとして合意形成支援ツールが必要</li>
	      <li><font color=red>本研究では、D-ADDで行われる合意形成のモデルを提案しツールのプロトタイプの実装を行う</font></li>
	      <li><font color=red>また、実際に例題の入力を行い、D-ADDにおける合意形成のあり方についての分析を行った</font></li>
	  </ul>
      </article>

      <article>
	  <h3>D-ADD(DEOS Agreement Description Database)の概要</h3>
	  <ul>
	      <li>3層構造</li>
	      <p class="center">
		  <img src="./pic/d_add.png" style="width:40%;"/>
	      </p>
	      <li>基本ツール層：D-ADDにおける基本ツール。Webアプリケーションとして合意形成支援を実装</li>
	      <li>モデル層：基本ツール層で扱うデータのモデルの定義。議論のモデルを実装</li>
	      <li>リポジトリ層：D-ADDで扱うデータベース。GraphDBを使って実装</li>
	  </ul>
      </article>

      <article>
	  <h3>D-ADD 説明責任と合意形成</h3>
	  <ul>
	      <li>システム障害発生時、D-ADDは説明責任を果たさなければならない</li>
	      <li>説明責任：障害が発生した理由、次から障害を起こさせないことを説明する責任</li>
	      <li>「なぜそのようなシステムになったのか」を説明しなければならない</li>
	      <li>そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべき</li>
	  </ul>
	  <p><font color=red size=6>D-ADD自身に合意形成を行う機能が必要となってくる</font></p>
      </article>

      <article>
	  <h3>合意形成機能の提案・実装</h3>
	  <ul>
	      <li>合意を取るためのモデルを提案</li>
	      <li>提案するモデル</li>
	      <ul>
		  <li>合意形成を主張・関係・ユーザの要素から構成する</li>
		  <li>まず命題となる合意を取りたい主張があり、それに対する別の主張を立てることで議論を深めていく</li>
		  <li>主張同士には関係が張られ、最初に作られた主張を根とし木構造で議論が深められていく</li>
	      </ul>
	      <p style="text-align:center;">
		  <img src="./pic/claim_tree_structure.png" style="width:40%;"/>
	      </p>
	  </ul>
      </article>

      <article>
	  <h3>モデルの概要</h3>
	  <ul>
	      <li>木構造には閉路が含まれないため、循環論法を生じさせないという狙いがある</li>
	      <li>ユーザ・主張・関係は以下のように定義される</li>
	      <ul>
		  <li>ユーザ：合意形成の参加者</li>
		  <li>主張：ユーザが作成した合意をとりたい、議論すべき内容を含むもの</li>
		  <li>関係：ユーザと主張、もしくは互いに異なる主張と主張の繋がりの種類を表す。反論、質問、提案等がある</li>
	      </ul>
	      <li>ユーザと主張はノード、関係はエッジとして扱われる</li>
	  </ul>
      </article>

      <article>
	  <h3>議論は主張の木構造で表される</h3>
	  <ul>
	      <li>主張を合意させるには、合意要求を出している全員から合意を受けることが必要</li>
	      <li>関係した主張の合意状態によっても全体の合意状態が変化</li>
	      <ul>
		  <li>反論：反論となる子の主張が合意された場合親の主張は合意されない。反論の主張は否認しなければならない。</li>
		  <li>質問：質問となる主張は合意しなければならない。</li>
		  <li>提案：提案となる主張はどの状態であろうと親の合意状態に影響を与えない。</li>
	      </ul>
	      <li>子供の合意状態によって、全体の合意状態の計算がすすむ</li>
	  </ul>
      </article>

      <article>
	  <h3>木構造で議論を表した例</h3>
	  <ul>
	      <p style="text-align:center" id="animation">
		  <span id='prev'><font color=blue>prev</font></span>
		  <span id='next'><font color=blue>next</font></span>
		  <br>
		  <img id='aniImage' src="./pic/animation5.png"/ style="height:60%;">
	      </p>
	      <br>
	  </ul>
      </article>

<script>
var IMAGE_SRC = [];
var CURRENT_NUM = -1;
IMAGE_SRC.push({ src:'./pic/animation1.png', style:'height:15%;'});
IMAGE_SRC.push({ src:'./pic/animation2.png', style:'height:40%;'});
IMAGE_SRC.push({ src:'./pic/animation3_0.png', style:'height:60%;'});
IMAGE_SRC.push({ src:'./pic/animation3.png', style:'height:60%;'});
IMAGE_SRC.push({ src:'./pic/animation4.png', style:'height:60%;'});
IMAGE_SRC.push({ src:'./pic/animation5_0.png', style:'height:60%;'});
IMAGE_SRC.push({ src:'./pic/animation5.png', style:'height:60%;'});
function changeImage(num) {
    var imageInfo = IMAGE_SRC[num];
    $('#aniImage').attr('style', imageInfo.style);
    $('#aniImage').attr('src', imageInfo.src);
}

function animationNext() {
    if (CURRENT_NUM < IMAGE_SRC.length-1) CURRENT_NUM++;
    
    changeImage(CURRENT_NUM);
}

function animationPrev() {
    if (0 < CURRENT_NUM) CURRENT_NUM--;
    changeImage(CURRENT_NUM);
}
function init() {
    $('#prev').click(animationPrev);
    $('#next').click(animationNext);
}

init();
</script>


      <article>
	  <h3>Webアプリケーションのユースケース図</h3>
	  <ul>
	      <p style="text-align:center;">
		  <img src="./pic/usecase.png" style="width:50%;">
	      </p>
	  </ul>
      </article>

      <article>
	  <h3>Webアプリケーションの実装</h3>
	  <ul>
	      <li>サーバサイドの実装はJavaを使用</li>
	      <li>クライアントサイドはJavaScript,HTML,CSSで実装</li>
	      <p class="center">
		  <img src="./pic/architecture.png">
	      </p>
	      <li>Webアプリケーションフレームワークplay frameworkでREST APIを提供</li>
	      <li>TinkerPopはGraphDB</li>
	  </ul>
      </article>

      <article>
	  <h3>モデルの実装に使用したデータベース</h3>
	  <ul>
	      <li>議論は木構造で表される。木構造は閉路の無いグラフ</li>
	      <li>そこで今回モデルの実装にGraphDBのTinkerGraphを使用</li>
	      <li>GraphDBはノードとエッジによりグラフでデータを表現</li>
	      <li>ノード、エッジともにプロパティを持つことができ、プロパティはkey,valueでデータを保持</li>
	      <li>エッジにはLabelが付けられ、また向き(Direction)がある</li>
	      <li>ノードは自身に繋がっているエッジをLabelとDirectionで指定することで次のノードの情報を得る</li>
	      <!--
	      <li>この動作を走査(Traverse)という</li>	  
	      -->
	  </ul>
      </article>

      <article>
	  <h3>GraphDBによるモデルの表現</h3>
	  <ul>
	      <li>主張、ユーザをノードで表し、関係をエッジで表す</li>
	      <p style="text-align:center;">
		  <img src="./pic/claim_tree_structure.png" style="width:40%;"/>
	      </p>
	      <li>「作者」や「合意要求」もエッジで表す</li>
	      <p style="text-align:center;">
		  <img src="./pic/usernode_sample.png" style="width:40%;"/>
	      </p>
	  </ul>
      </article>

      <article>
	  <h3>各ノードのプロパティ</h3>
	  <ul>
	      <li>ユーザノードは特にプロパティは持たない</li>
	      <li>主張ノードは以下のプロパティを持つ</li>
	      <ul>
		  <li>status：主張の合意状態を表す。 passed, failed, unknown の状態がある</li>
		  <li>title：主張のタイトル</li>
		  <li>content：主張の内容</li>
		  <li>toulmin：トゥールミンモデルにおける主張以外の5つの要素が入る</li>
		  <li>timestamp：作成された時間を示すタイムスタンプ</li>
	      </ul>
	      <li>passedは合意されている、failedは否認された、unknownはどちらでも無いという合意状態を表す</li>
	  </ul>
      </article>

      <article>
	  <h3>エッジのプロパティ</h3>
	  <ul>
	      <li>主張同士を繋ぐエッジはプロパティを持たない</li>
	      <li>ユーザへ伸びる合意要求のエッジが以下のプロパティを持つ</li>
	      <ul>
		  <li>status：ユーザの主張に対する合意状態を表す。passed, pend, unknownの状態がある</li>
	      </ul>
	      <p class="center">
		  <img src="./pic/request.png">
	      </p>
	      <li>基本、各主張は自身に繋がっている合意要求の関係にあるエッジのstatusが全てpassedかfailedとなる
	      ことで合意か否認にされたとみなされる</li>
	  </ul>
      </article>

      <article>
	  <h3>時系列ごとにみられる議論と合意状態</h3>
	  <ul>
	      <li>合意形成が行われる様子を時系列でみたい</li>
	      <li>木のコピーを行い過去の合意状態を見ることができるようにする</li>
	      <p class="center">
		  <img src="./pic/Temporal.png">
	      </p>
	      <li>木全体のコピーを行い、prevの関係になるエッジで繋げる</li>
	      <li>prevをたどることで以前の合意状態と木を見ることができ、議論の流れを知ることができる</li>
	  </ul>
      </article>

      <article>
	  <h3>合意形成支援Webアプリケーションとredmineとの比較</h3>
	  <ul>
	      <li>例題として入力するデータは琉球大学情報工学科のシステム管理班が行った実際の作業</li>
	      <li>作成したツールとredmineの表示の比較</li>
	  </ul>
      </article>

      <article>
	  <h3>合意形成支援Webアプリケーションでの表示</h3>
	  <ul>
	      <p class="center">
		  <img src="./pic/compare_sample.png" style="width:65%;">
	      </p>
	      <li>各主張のつながりが分かりやすい</li>
	  </ul>
      </article>

      <article>
	  <h3>redmineとの比較</h3>
	  <ul>
	      <p class="center">
		  <img src="./pic/redmine_sample.png" style="width:80%;">
	      </p>
	      <li>redmineはチケットによりプロジェクトを管理する</li>
	      <li>親チケットのbldsvをリフレッシュする、と子チケットのセカンダリDNSサーバをたてる、の繋がりがわかりづらい</li>
	  </ul>
      </article>

      <article>
	  <h3>時系列にみることの有用性</h3>
	  <ul>
	      <li>議論を行ううちに、一度は合意されたが否認され、また合意されるとった主張がでてくるかもしれない</li>
	      <li>最新の合意状態をみるだけでは確認できない</li>
	      <table style="width:100%;">
		  <tr>
		      <td style="border-style:none; width:33%;">
			  最新
		      </td>
		      <td style="border-style:none; width:33%;">
			  1つ前
		      </td>
		      <td style="border-style:none; width:33%;">
			  2つ前
		      </td>
		  </tr>
		  <tr>
		  <td style="border-style:none; width:33%;">
		      <p class="center">
			  <img src="./pic/temporal_sample3.png" style="width:100%;">
		      </p>
		  </td>
		  <td style="border-style:none; width:33%;">
		      <p class="center">
			  <img src="./pic/temporal_sample2.png" style="width:100%;">
		      </p>
		  </td>
		  <td style="border-style:none; width:33%;">
		      <p class="center">
			  <img src="./pic/temporal_sample1.png" style="width:100%;">
		      </p>
		  </td>
		  </tr>
	      </table>
	      <li>時系列にみることができれば、その議論の流れを知ることができる</li>
	      <li>説明責任に使う情報を増やすことができる</li>
	  </ul>
      </article>

      <article>
	  <h3>まとめ</h3>
	  <ul>
	      <li>議論のモデルを考えWebアプリケーションとして合意形成支援ツールの実装を行い
	      D-ADDにおける合意形成支援についての追求を行った</li>
	      <li>木構造のモデルの提案とGraphDBを用いた実装を行った</li>
	      <li>実際に作成したWebアプリケーションに大学のサーバ管理班の作業となるデータを入力し、redmineに入力した場合と比較した</li>
	      <li>redmineで入力した場合に比べ、各主張同士の関係がみやすいことを確認した</li>
	      <li>時系列的に流れをみることで、合意までの議論の流れがより分かりやすくなり、合意全体の
	      理解を支援できる可能性を見ることができた</li>
	      <li>本システムを使うことにより、DEOSプロセスにおける説明責任を明確にするためのツールを提供することができた</li>
	  </ul>
      </article>

      <article>
	  <h3>今後の課題</h3>
	  <ul>
	      <li>議論の木構造が巨大になった際の対処も考えなければならない</li>
	      <li>内容が同じ主張の検知を行っていない。検知をしてマージを行うなり、何かしら解決する機能を考える必要がある</li>
	      <li>同時に、マージが行われた主張が及ぼす影響をより分かりやすくみせることも理想である</li>
	      <li>さらに、本実装では主張同士の関係に反論・質問・提案だけであったが、更に増やすことが可能である</li>
	      <li>関係を増やす場合は反論・質問・提案のを元に合意状態へと影響を与える主張を作成する</li>
	      <li>どのような関係があればより合意形成支援を行うことができるのか考え行くべきである</li>
	  </ul>
      </article>

      <article>
	  <h3>デモ</h3>
	  <ul>
	      <a href="http://nitch.cr.ie.u-ryukyu.ac.jp:9000">http://nitch.cr.ie.u-ryukyu.ac.jp:9000</a>
	      <li>ユーザ名：Akifumiでログイン</li>
	  </ul>
      </article>

      <article>
	  <h3>トゥールミンモデル</h3>
	  <ul>
	      <li></li>
	      <li></li>
	  </ul>
      </article>

  </body>
</html>