Mercurial > hg > Papers > 2013 > nobuyasu-sigos
view presen/index.html @ 70:708ac2407a24
modified 4.4
| author | Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp> |
|---|---|
| date | Wed, 24 Apr 2013 01:22:58 +0900 |
| parents | 059d1777fd53 |
| children | e4839c4b593b |
line wrap: on
line source
<!DOCTYPE html> <html> <head> <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> <h1><font size=10em> ディペンダブルシステムのための木構造を用いた合意形成データベースの提案と実装 </font> </h1> <p> 琉球大学 大城信康 <br> 26 April 2013 </p> </article> <!-- <article> <h3>目次</h3> <ul> <li>研究の目的と背景</li> <li>D-ADD</li> <li>提案する合意形成のモデル</li> <li>モデルの実装</li> <li>モデルの合意形成支援Webアプリケーションへの実装</li> <li>合意形成支援Webアプリケーションの考察</li> <li>まとめ</li> </ul> </article> --> <article> <h3>研究の目的と背景</h3> <ul> <li>ITシステムが巨大化していくにつれ、障害発生時例が社会に与える影響もより大きな物となる。</li> <li>それに伴い、ITシステムにおけるディペンダビリティへの注目が増している。 </li> <li>そこでDEOSプロジェクトはITシステムにおけるディペンダビリティを担保する技術体系をまとめ、制度化、更には事業化を目指している。</li> <li>DEOSプロジェクトは、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供するシステム構築法の開発を 目標としている。</li> <li>DEOSプロジェクトではそれらの技術体系を「オープンシステムディペンダビリティ」として定義し、それをDEOSプロセスとしてまとめた。</li> </ul> </article> <article> <h3>研究の目的と背景</h3> <ul> <li>DEOSプロセスにおいて、全てのデータを保持するD-ADDと呼ばれるデータベースがある。</li> <!-- ステークホルダの意味を述べておく必要があるかも --> <!-- ステークホルダについての説明は論文2章で「プロジェクトに関わる人」として述べてはいる --> <li>D-ADDで扱うデータにはステークホルダ間で合意された契約書も含まれる。そのため、D-ADDに基本ツールとして合意形成支援ツールが必要である。</li> <li>本研究では、D-ADDで行われる合意形成のモデルを提案しツールのプロトタイプの実装を行う。</li> <li>また、実際に例題の入力を行い、D-ADDにおける合意形成のあり方についての追求を行う。</li> </ul> </article> <article> <h3>D-ADD(DEOS Agreement Description Database)</h3> <ul> <li>D-ADDはステークホルダ合意と対象のシステムに依存するプログラム・コード、 及び対象システムの運用状態との間の一貫性を常に保つための機構を提供する。</li> <p style="text-align:center;"> <img src="./pic/d_add.png" style="width:35%;"/> </p> <li>基本ツール層：D-ADDにおける基本ツール</li> <li>モデル層：基本ツール層で扱うデータのモデルの定義</li> <li>リポジトリ層：D-ADDで扱うデータベース</li> </ul> </article> <article> <h3>D-ADD 説明責任と合意形成</h3> <ul> <li>システム障害発生時、D-ADDは説明責任を果たさなければならない</li> <li>説明責任：障害が発生した理由、次から障害を起こさせないことを説明する責任</li> <li>「なぜそのようなシステムになったのか」を説明しなければならない</li> <li>そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべきである </li> <li>そこでD-ADD自身に合意形成を行う機能が必要となってくる</li> <li>合意形成を行うシステムをWebアプリケーションとして提供する</li> </ul> </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> <li>各関係の主張が与える合意状況への影響についての説明は以下となる</li> <ul> <li>反論：反論となる子の主張が合意された場合親の主張は合意されない。反論の主張は否認しなければならない。</li> <li>質問：質問となる主張は合意しなければならない。</li> <li>提案：提案となる主張はどの状況であろうと親の合意状況に影響を与えない。</li> </ul> </ul> </article> <article> <h3>合意状況の計算</h3> <ul> <li>木構造で議論を表した例</li> <p style="text-align:center"> <img src="./pic/TOModel2_2.png"/ style="width:60%;"> </p> <li>根となる主張があり、反論となる主張と質問となる主張と繋がっている</li> <li>根の主張の合意を取るため、反論で繋がっている主張は否認の状態であり、質問は合意の状態となっている</li> </ul> </article> <article> <h3>主張のモデル</h3> <ul> <li>D-ADDでの合意形成支援は、議論だけでなく主張単体ののモデルについても考える。</li> <li>議論のモデルとは別に主張単体のモデルについても考える</li> <li>今回はトゥールミンモデルを内包した</li> <p class="center"> <img src="./pic/toulmin.png"> </p> <li>トゥールミンモデルだけでなく、他の主張モデルも使えるように考えていくつもりである。</li> </ul> </article> <article> <h3>Webアプリケーションの実装</h3> <ul> <li>Webアプリケーションのユースケース図</li> <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>サーバサイドがREST APIを用意し、主にJSONデータを用いてデータのやりとりを行う</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> </ul> </article> <article> <h3>GraphDBによるモデルの表現</h3> <ul> <li>主張、ユーザをノードで表し、関係をエッジで表す</li> <p style="text-align:center;"> <img src="./pic/TOModel0_2.png" style="width:70%;"> </p> <li>「作者」や「合意要求」もエッジで表す</li> </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：ユーザの主張に対する合意状態を表す。agreed, pend, unknownの状態がある</li> </ul> </ul> </article> <article> <h3></h3> <ul> <li></li> <li></li> <li></li> </ul> </article> <article> <h3></h3> <ul> <li></li> <li></li> <li></li> </ul> </article> <article> <h3></h3> <ul> <li></li> <li></li> <li></li> </ul> </article> <article> <h3></h3> <ul> <li></li> <li></li> <li></li> </ul> </article> </body> </html>