changeset 15:c7ab31269230

update some file
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Sat, 15 Feb 2020 18:37:06 +0900
parents c3c24250dc6b
children 7293b6481e32
files final_main/chapter1/chapter1.tex final_main/chapter2/chapter2.tex final_main/chapter4/chapter4.tex final_main/main.pdf final_pre/final_pre.tex
diffstat 5 files changed, 30 insertions(+), 14 deletions(-) [+]
line wrap: on
line diff
--- a/final_main/chapter1/chapter1.tex	Sat Feb 15 17:48:53 2020 +0900
+++ b/final_main/chapter1/chapter1.tex	Sat Feb 15 18:37:06 2020 +0900
@@ -14,10 +14,10 @@
 複数人の編集がリアルタイムに同期されるリモートエディタには, 既存の物としてVisual Studio Code(以下VScode)のremote session がある. 
 しかし, 編集のセッションに参加するユーザ全員がVSCodeを使うことになり, またVSCodeの環境を導入する必要がある.
 
-そこで,セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを作成したい. 
+セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを作成したい. 
 アプリケーションの形に作成することにより, 開発のための環境に手間を使うことなく, ユーザーが慣れ親しんだエディタを利用できるようしたい.
 これによりリモートワークやペアプログラミングを, 手軽に行える機能を作る.
-また, 最終的にはVScodeのリモートセッションとの接続も目指して制作したい.
+また, 最終的にはVScodeのリモートセッションとの接続も目指している.
 
 
 先行研究ではネットワークをリング型で構成しトークンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといった問題点が見られた. 
--- a/final_main/chapter2/chapter2.tex	Sat Feb 15 17:48:53 2020 +0900
+++ b/final_main/chapter2/chapter2.tex	Sat Feb 15 18:37:06 2020 +0900
@@ -7,16 +7,17 @@
 リモートエディタとは他のマシン上に存在するファイルのバッファを別デバイスから開いて編集, 保存することができる機能である.
  
 本研究ではこのリモートエディタを複数人が同時に同じファイルを編集し, その上変更がリアルタイムに反映されるように設計する. 
-この章では同期リモートエディタの実装の上で踏んだプロセスや,  開発の上で問題となる点と解決策について説明する。
+この章では同期式リモートエディタの実装の上で踏んだプロセスや,  開発の上で問題となる点と解決策について説明する。
 
 \section{document listenerによる編集オフセット番号の読み取り}
-    エディタ同士の基本通信環境の構成のため, Chrisitie と同様にjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 
+    本研究の通信部分を構成する分散フレームワークChrisitie はjavaで開発する. 
+したがってエディタ同士の基本通信環境の構成のため, Chrisitie と同様にjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 
 自作エディタは java. swingの機能で構成されており, コードをオフセット番号で取り扱っている. 
 
 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. 
 DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った. 
 
-insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様にバッファ内の文字のいずれかが削除が行われた際に実行される. 
+insertUpdateメソッドではエディタのバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様にバッファ内の文字のいずれかが削除が行われた際に実行される. 
 他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった. 
 
 コード\ref{code:DocumentListener}はinsertUpdate, removeUpdateの記述部分である. 
@@ -41,8 +42,10 @@
 といった点が挙げられる. 
 ソースコード:\ref{code:Command}は書き込み, 送信を行う際の命令をクラスとして作成したものである. 
 このクラスのインスタンスを命令オブジェクトとして送信し合う. 
+実際にChristieで命令オブジェクトの送受信を実装した解説は第四章にて行う. 
 
-\lstinputlisting[caption=Commandパターンとして実装した命令, label=code:Command]{./src/Command.java}
+\lstinputlisting[caption=Commandパターンで実装した命令クラス, label=code:Command]{./src/Command.java}
+
 
 \section{命令オブジェクトを実装する際に起きた問題}
 インスタンス化した命令を他ノードに送信する際にエラーが発生し, 送信に失敗してしまうという問題が発生した.
@@ -155,17 +158,21 @@
 と言った方法で行うことができる.
 これを削除, 文字列の置き換えにもそれぞれ対応する方法を作ることによりズレの修正を行う.
 
-また, 上記の修正方法のテストコードを試みた.
-テストコードを書き上げる中でこの方法でも網羅できていない問題点や実装上の問題がみられた.
+上記の修正方法のテストコードを試みた.
+構成としては現時点では問題が見られていないが, 実装した際に初めて判明する通信速度や複数の独立した処理による影響も対処しなければならない可能性がある.
+
+また, これからの実装を考えると
 \begin{itemize}
 \item 既存のエディタ(emacsやvim)のバッファ処理はオフセット単位で行われていない.
+\item コマンドを保持し続けるとメモリ容量に無駄が発生する.
 \item コマンドのput(送信)失敗についての想定ができていない.
-\item 現在のChristieでは リスト型や Stack型がputできない.
-\item コマンドを保持し続けるとメモリ容量に無駄が発生する.
 \end{itemize}
-と言った問題点が露見した. 
-これらの問題についての対応方法を模索する必要がある.
-また実装した際に初めて判明する通信速度や複数の独立した処理による影響も対処しなければならない可能性がある.
+といった点を修正する必要がある. 
+
+
+
+
+
 
 
 
--- a/final_main/chapter4/chapter4.tex	Sat Feb 15 17:48:53 2020 +0900
+++ b/final_main/chapter4/chapter4.tex	Sat Feb 15 18:37:06 2020 +0900
@@ -65,7 +65,16 @@
 \lstinputlisting[caption=FinishHelloWorld, label=code:FinishHelloWorld]{./src/FinishHelloWorld.java}
 
 
+\section{Chrisiteにおけるコマンドパターンの実装}
+コード\ref{code:DoCommand}はChristie上でのコマンドパターン構成による命令の送り合いを実装したテストコードである.
 
+17行目:RTCommand cmd = new RTCommand("Z", 0); にて命令コマンドのインスタンスを作成, 同時に命令の内容を入力する.
+この場合, エディタバッファのオフセット0に文字列”Z”を入力するという意味の命令オブジェクトを作れる.
+
+そして, 18行目:gm.getDGM("remote").put("command",cmd); にて作成したコマンドをリモートのDGMへ送信する.
+実際に実装したコードにはこの命令にさらに発進したノード名やコマンド番号が含まれる.
+
+\lstinputlisting[caption=命令オブジェクトを作成して送信するテストコード, label=code:DoCommand]{./src/StartRemoteTake.java}
 
 
 \section{TopologyManager について}
Binary file final_main/main.pdf has changed
--- a/final_pre/final_pre.tex	Sat Feb 15 17:48:53 2020 +0900
+++ b/final_pre/final_pre.tex	Sat Feb 15 18:37:06 2020 +0900
@@ -59,7 +59,7 @@
 複数人の編集がリアルタイムに同期されるリモートエディタには, 既存の物としてVisual Studio Code(以下VScode)のremote session がある. 
 しかし, 編集のセッションに参加するユーザ全員がVSCodeを使うことになり, またVSCodeの環境を導入する必要がある.
 
-そこで,セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを作成したい. 
+セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを作成したい. 
 アプリケーションの形に作成することにより, 開発のための環境に手間を使うことなく, ユーザーが慣れ親しんだエディタを利用できるようしたい.
 
 先行研究ではネットワークをリング型で構成しトークンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといった問題点が見られた.