Mercurial > hg > Papers > 2013 > nobuyasu-sigos

changeset 83:e3ea612748f7

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 Thu, 25 Apr 2013 02:33:09 +0900
parents 8f6f7a50299a
children 5ad6483b895d
files presen/index.html
diffstat 1 files changed, 58 insertions(+), 45 deletions(-) [+]
line wrap: on
line diff
--- a/presen/index.html	Thu Apr 25 00:54:25 2013 +0900
+++ b/presen/index.html	Thu Apr 25 02:33:09 2013 +0900
@@ -59,10 +59,11 @@
 	  <h3>DEOS(Dependability Engineering for Open Systems)</h3>
 	  <ul>
 	      <p class="center">
-		  <img src="./pic/deos_proccess.png" style="width:55%;">
+		  <img src="./pic/deos_proccess.png" style="width:70%;">
 	      </p>
-	      <li>変化対応サイクル：ステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクル</li>
-	      <li>障害対応サイクル：障害に対して迅速に対応して障害による被害を最小化するためのサイクル</li>
+	      <li>変化対応サイクル：ステークホルダ間で決定されたサービスの運用に関する取り決め等に対応</li>
+	      <li>障害対応サイクル：変化対応サイクルで決められた通りにサービスを稼働。障害に対して未然回避・迅速対応・原因追求
+	      も行う</li>
 	  </ul>
       </article>
 
@@ -71,17 +72,15 @@
 	  <ul>
 	      <li>D-ADDはDEOSプロセスで扱われるデータ、システムのログ、契約書、ソースコードといったものを保持するデータベース</li>
 	      <li>D-ADDで扱うデータにはステークホルダ間で合意された契約書も含まれる。そのため、D-ADDに基本ツールとして合意形成支援ツールが必要</li>
-	      <li>本研究では、D-ADDで行われる合意形成のモデルを提案しツールのプロトタイプの実装を行う。</li>
-	      <li>また、実際に例題の入力を行い、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>
+	  <h3>D-ADD(DEOS Agreement Description Database)の概要</h3>
 	  <ul>
-<!--
-	      <li>D-ADDにおける</li>
--->
+	      <li>3層構造</li>
 	      <p class="center">
 		  <img src="./pic/d_add.png" style="width:40%;"/>
 	      </p>
@@ -97,14 +96,13 @@
 	      <li>システム障害発生時、D-ADDは説明責任を果たさなければならない</li>
 	      <li>説明責任：障害が発生した理由、次から障害を起こさせないことを説明する責任</li>
 	      <li>「なぜそのようなシステムになったのか」を説明しなければならない</li>
-	      <li>そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべきである </li>
-	      <li>そこでD-ADD自身に合意形成を行う機能が必要となってくる</li>
-	      <li>合意形成を行うシステムをWebアプリケーションとして提供する</li>
+	      <li>そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべきである</li>
 	  </ul>
+	  <p><font color=red size=6>D-ADD自身に合意形成を行う機能が必要となってくる</font></p>
       </article>
 
       <article>
-	  <h3>合意形成機能の提案、実装</h3>
+	  <h3>合意形成機能の提案・実装</h3>
 	  <ul>
 	      <li>合意を取るためのモデルを提案する</li>
 	      <li>提案するモデル</li>
@@ -127,36 +125,33 @@
 	      <ul>
 		  <li>ユーザ：合意形成の参加者</li>
 		  <li>主張：ユーザが作成した合意をとりたい、議論すべき内容を含むもの</li>
-		  <li>関係：ユーザと主張、もしくは互いに異なる主張と主張の繋がりの種類を表す</li>
+		  <li>関係：ユーザと主張、もしくは互いに異なる主張と主張の繋がりの種類を表す。反論、質問、提案等がある</li>
 	      </ul>
 	      <li>ユーザと主張はノード、関係はエッジとして扱われる</li>
 	  </ul>
       </article>
 
       <article>
-	  <h3>合意状態の計算</h3>
+	  <h3>議論は主張の木構造で表される</h3>
 	  <ul>
-	      <li>主張を合意させるには、合意要求を出している全員から合意を受ける必要がある</li>
-	      <li>子供となる主張がある場合、関係次第では子となる主張の合意状態も親の主張の合意状態に影響を与える</li>
-	      <li>各関係の主張が与える合意状態への影響についての説明は以下となる</li>
+	      <li>主張を合意させるには、合意要求を出している全員から合意を受けることが必要</li>
+	      <li>関係した主張の合意状態によっても全体の合意状態が変化</li>
 	      <ul>
 		  <li>反論：反論となる子の主張が合意された場合親の主張は合意されない。反論の主張は否認しなければならない。</li>
 		  <li>質問：質問となる主張は合意しなければならない。</li>
 		  <li>提案：提案となる主張はどの状態であろうと親の合意状態に影響を与えない。</li>
 	      </ul>
-
+	      <li>子供の合意状態によって、全体の合意状態の計算がすすむ</li>
 	  </ul>
       </article>
 
       <article>
-	  <h3>合意状態の計算</h3>
+	  <h3>木構造で議論を表した例</h3>
 	  <ul>
-	      <li>木構造で議論を表した例</li>
 	      <p style="text-align:center">
-		  <img src="./pic/TOModel2_2.png"/ style="width:60%;">
+		  <img src="./pic/animation5.png"/ style="height:60%;">
 	      </p>
-	      <li>根となる主張があり、反論となる主張と質問となる主張と繋がっている</li>
-	      <li>根の主張の合意を取るため、反論で繋がっている主張は否認の状態であり、質問は合意の状態となっている</li>
+	      <br>
 	  </ul>
       </article>
 
@@ -172,25 +167,28 @@
       <article>
 	  <h3>Webアプリケーションの実装</h3>
 	  <ul>
-	      <li>サーバサイドの実装はJavaを使用した</li>
-	      <li>クライアントサイドはJavaScript,HTML,CSSで実装を行った</li>
+	      <li>サーバサイドの実装はJavaを使用</li>
+	      <li>クライアントサイドはJavaScript,HTML,CSSで実装</li>
 	      <p class="center">
 		  <img src="./pic/architecture.png">
 	      </p>
-	      <li>サーバサイドがREST APIを用意し、主にJSONデータを用いてデータのやりとりを行う</li>
+	      <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で指定することで次のノードの情報を得る。
-		  この動作を走査(Traverse)という</li>
+	      <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>
 
@@ -230,12 +228,12 @@
 	      <li>主張同士を繋ぐエッジはプロパティを持たない</li>
 	      <li>ユーザへ伸びる合意要求のエッジが以下のプロパティを持つ</li>
 	      <ul>
-		  <li>status：ユーザの主張に対する合意状態を表す。agreed, pend, unknownの状態がある</li>
+		  <li>status：ユーザの主張に対する合意状態を表す。passed, pend, unknownの状態がある</li>
 	      </ul>
 	      <p class="center">
 		  <img src="./pic/request.png">
 	      </p>
-	      <li>基本、各主張は自身に繋がっている合意要求の関係にあるエッジのstatusが全てagreedかfailedとなる
+	      <li>基本、各主張は自身に繋がっている合意要求の関係にあるエッジのstatusが全てpassedかfailedとなる
 	      ことで合意か否認にされたとみなされる</li>
 	  </ul>
       </article>
@@ -244,7 +242,7 @@
 	  <h3>時系列ごとにみられる議論と合意状態</h3>
 	  <ul>
 	      <li>合意形成が行われる様子を時系列でみたい</li>
-	      <li>そこで、木のコピーを行い過去の合意状態を見ることができるようにする</li>
+	      <li>木のコピーを行い過去の合意状態を見ることができるようにする</li>
 	      <p class="center">
 		  <img src="./pic/Temporal.png">
 	      </p>
@@ -254,11 +252,10 @@
       </article>
 
       <article>
-	  <h3>デモ</h3>
+	  <h3>合意形成支援Webアプリケーションとredmineとの比較</h3>
 	  <ul>
-	      <li>デモ</li>
-	      <a href="http://nitch.cr.ie.u-ryukyu.ac.jp:9000">http://nitch.cr.ie.u-ryukyu.ac.jp:9000</a>
-	      <li>ユーザ名：Akifumiでログイン</li>
+	      <li>例題として入力するデータは琉球大学情報工学科のシステム管理班が行った実際の作業</li>
+	      <li>作成したツールとredmineの表示の比較</li>
 	  </ul>
       </article>
 
@@ -273,10 +270,10 @@
       </article>
 
       <article>
-	  <h3>redmineでの表示</h3>
+	  <h3>redmineとの比較</h3>
 	  <ul>
 	      <p class="center">
-		  <img src="./pic/redmine_sample.png" style="width:85%;">
+		  <img src="./pic/redmine_sample.png" style="width:80%;">
 	      </p>
 	      <li>redmineはチケットによりプロジェクトを管理する</li>
 	      <li>親チケットのbldsvをリフレッシュする、と子チケットのセカンダリDNSサーバをたてる、の繋がりがわかりづらい</li>
@@ -287,7 +284,7 @@
 	  <h3>時系列にみることの有用性</h3>
 	  <ul>
 	      <li>議論を行ううちに、一度は合意されたが否認され、また合意されるとった主張がでてくるかもしれない</li>
-	      <li>そのような場合は最新の合意状態をみるだけでは確認できない</li>
+	      <li>最新の合意状態をみるだけでは確認できない</li>
 	      <table style="width:100%;">
 		  <tr>
 		      <td style="border-style:none; width:33%;">
@@ -319,7 +316,7 @@
 		  </tr>
 	      </table>
 	      <li>時系列にみることができれば、その議論の流れを知ることができる</li>
-	      <li>これにより説明責任に使う情報を増やすことができる</li>
+	      <li>説明責任に使う情報を増やすことができる</li>
 	  </ul>
       </article>
 
@@ -349,5 +346,21 @@
 	  </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>