--- a/paper/nozomi-master.tex	Mon Feb 05 17:54:31 2018 +0900
+++ b/paper/nozomi-master.tex	Tue Feb 06 03:56:16 2018 +0900
@@ -197,9 +197,9 @@
 データの圧縮を指定したい場合、Akka、Hazelcastはシリアライザが用意されているため、そのメソッドを呼び出すことで圧縮伸長を行う。
 また、転送を指定したい場合、Akkaにはforwardメソッドがあるためそれを呼び出すことで受け取ったデータの転送が可能だが、Hazelcastは一つのMapへのアクセスに見立てているため、転送にもputを用いる。
 
-一方でAliceは圧縮の展開と転送を同時に行うことを想定した圧縮・転送機能を持っている。
-Data Segment内に圧縮と非圧縮の両形式を同時に持てるため、受け取った圧縮データを展開をしながら圧縮したまま別ノードに転送することができる。
-また、圧縮するには送信する宛先ラベルに"compressed"とつけるだけでよく、データ取得時に自動で展開もされるため、プログラマがメソッドの呼び出しを追加する必要がなく圧縮・非圧縮を簡単に切り替えられる。
+一方でAliceは圧縮の伸長と転送を同時に行うことを想定した圧縮・転送機能を持っている。
+Data Segment内に圧縮と非圧縮の両形式を同時に持てるため、受け取った圧縮データを伸長をしながら圧縮したまま別ノードに転送することができる。
+また、圧縮するには送信する宛先ラベルに"compressed"とつけるだけでよく、データ取得時に自動で伸長もされるため、プログラマがメソッドの呼び出しを追加する必要がなく圧縮・非圧縮を簡単に切り替えられる。
 
 \newpage
 
@@ -281,12 +281,6 @@
 \begin{itemize}
 \item {\ttfamily void put(String managerKey, String key, Object val)}
 \end{itemize}
-putとupdate、flipはOutput DS APIと呼ばれ、DSをDSMに保存する際に用いる。
-peekとtakeはInput DS APIと呼ばれ、DSをDSMから取得する際に使用する。
-
-\begin{itemize}
-\item {\ttfamily void put(String managerKey, String key, Object val)}
-\end{itemize}
 DSをDSMに追加するためのAPIである。第一引数はLocal DSMかRemote DSMかといったManager名を指定する。そし
 て第二引数で指定されたkeyに対応するDSとして第三引数の値を追加する。
 
@@ -414,7 +408,7 @@
 リモートノードに大きなデータを送るために、データを圧縮したい場合がある。
 そこで、Aliceは圧縮をサポートしている。
 しかし、単に圧縮のメソッドを用意したわけではない。
-圧縮データの展開と、圧縮したまま別ノードへの転送を同時に実現したい場合があるため、Meta CSを介すことでDSに圧縮と非圧縮のデータを同時に持てるようにしている(図\ref{fig:compress})。
+圧縮データの伸長と、圧縮したまま別ノードへの転送を同時に実現したい場合があるため、Meta CSを介すことでDSに圧縮と非圧縮のデータを同時に持てるようにしている(図\ref{fig:compress})。
 
 \begin{figure}[h]
 \begin{center}
@@ -446,7 +440,7 @@
 \lstinputlisting[label=src:after,caption=圧縮したDSを扱うCSの例]{source/afterCompress.java}
 
 このようにコードの変更を抑えて圧縮できるため、他の計算部分を変えずにデータ形式が指定できる。
-また、DSを取り出す際もasClass()内部で自動で展開が行われるため、コードの変更がなく、プログラマがデータの展開を考える必要がない。
+また、DSを取り出す際もasClass()内部で自動で伸長が行われるため、コードの変更がなく、プログラマがデータの伸長を考える必要がない。
 
 
 \subsection{TopologyManager}
@@ -492,10 +486,10 @@
 2.4で示したように、InputDSを記述するには、一度フィールドでReceiverをcreateして、その後Reveiverに対してsetKeyで待ち合わせるkeyを指定しなければならない。
 このようにインプットの処理が分離されてしまっていては、記述が煩雑な上にコードを読んだ際にどのkeyに対して待ち合わせを行っているのか直感的に分からない。
 
-さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう(ソースコード\ref{src:StartSetKey)})。
+さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう(ソースコード\ref{src:StartSetKey})。
 
     \lstinputlisting[label=src:StartSetKey, caption=setKeyを外部から呼び出す例]{source/StartSetKey.java}
-    \lstinputlisting[label=src:SetKey]{source/SetKey.java}
+    \lstinputlisting[label=src:SetKey, caption=外部setKeyによりどのkeyを待っているかがわからないCSの例]{source/SetKey.java}
 
 このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。
 これでは見通しが悪いため、どこでkeyを指定するのか明確にすべきである。
@@ -889,6 +883,16 @@
 REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。
 
 \chapter{再設計への考察}
+Christieではアノテーションを用いることで分離問題を解決することができた。
+このようにアノテーションを用いたAPIはAkkaやHazelcastにはないため、より記述性が高いフレームワークとなったと言える。
+
+また、設計をし直したことでAliceより幅広いMeta Computationの実装が容易になった。
+これにより細かな分散プログラムの実装が可能になった。
+ロケーション透過性の高いAkkaやHazelcastではこのようなプログラミングは困難である。
+
+keyを用いたプロトコル
+また、現在はノードごとにDGMとDGのkeyが与えられているが、将来的にはURLのような大域で使えるkeyを用意することでより手軽なRemoteDGMへのアクセスを提供できると考えられる。
+
 InputDGの指定において、CGにDGを宣言するというのは、DGをそのままflipできるようにするためであった。
 逆に言えばそれ以外でDataGear型でプログラマが利用することは少ない。
 そのため、DGを宣言せずにアノテーションから生成し完全にメタレイヤーに移すことで、より分かりやすい記述が可能だと考える。
@@ -896,12 +900,6 @@
 
 また、put/flipする際にDGM名を直接指定する書き方も、まだひと目でアウトプットしている部分が分かるようなシンタックスではないため、改善の余地がある。
 
-DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。
-当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。
-そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くすることが望ましい。
-
-また、現在はノードごとにDGMとDGのkeyが与えられているが、将来的にはURLのような大域で使えるkeyを用意することでより手軽なRemoteDGMへのアクセスを提供できると考えられる。
-
 \chapter{結論}
 \section{まとめ}
 本研究では、まず分散フレームワークに必要な要件を洗い出し、Akka、Hazelcastと比較しながら分散フレームワークAliceが分散性を意識して記述できる特徴をもつことを示した。
@@ -924,6 +922,12 @@
 CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。
 そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。
 
+
+\subsection*{Jungleとの統合}
+DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。
+当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。
+そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くすることが望ましい。
+
 \subsection*{GearsOSへの移行}
 GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。
 GearsOSではモデル検査機構akasya\cite{akasya}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。