--- a/paper/abstract.tex	Sun Feb 04 22:31:12 2018 +0900
+++ b/paper/abstract.tex	Mon Feb 05 00:35:52 2018 +0900
@@ -20,5 +20,19 @@
 \end{abstract}
 
 \begin{abstract_eng}
+In our laboratory, we propose a method of dividing and describing data as Data Segment and task as Code Segment.
+Data segment is a collection of basically data such as integers, character strings and structures.
+The Code Segment starts processing in parallel from the time when the input Data Segments are complete and outputs the Data segment of the calculation result. 
+Using this method, we developed a parallel distributed framework Alice which aims to describe a scalable distributed program with enhanced reliability. 
+
+In Alice, by interposing the process Meta Computation during normal processing, we can change the behavior without changing the code significantly.
+Alice can describe a practical distributed application, Meta Computation is confirmed from the example of TreeVNC to make it highly extendable with little specification change.
+However, when trying to implement MetaComputation such as NAT traversal, extension is difficult at present and redesign was found to be desirable.
+Along with that, I thought that improving counterintuitive API of Alice should guarantee type consistency and improve reliability.
+
+In this research, we designed the distributed framework Christie based on the findings obtained with Alice.
+Christie realizes highly reliable programming with a simple description by using Java Annotation for API.
+Also, by enabling multiple Data Gear Managers to be launched, we responded to expansion such as NAT traversal.
+
 \end{abstract_eng}
 

Binary file paper/nozomi-master.pdf has changed

--- a/paper/nozomi-master.tex	Sun Feb 04 22:31:12 2018 +0900
+++ b/paper/nozomi-master.tex	Mon Feb 05 00:35:52 2018 +0900
@@ -115,7 +115,6 @@
 しかし、これらをもつ分散プログラムをユーザーが一から記述することは容易ではない。
 なぜなら、並列で動く分散した資源を意識しながら記述するのは容易ではなく、また、どのように分散したノードの選択を行えば良いのか明確ではないからである。
 
-
 分散プログラムには以下の３つの要素がある。
 \begin{itemize}
 \item {ノード内の計算}
@@ -157,6 +156,8 @@
 各ノードにはラベル付きのプロキシであるRemote Data Segment Managerを立て、ラベルとkeyを指定してデータをtake/putするプロトコルとなっている。
 
 
+\newpage
+
 記述の面において、Akkaではメッセージが集中した場合にそれを処理するパターンマッチが増えてしまう問題や、複数のインプットを待ち合わせる際に記述が煩雑になる問題があった。
 しかしAliceはインプットを明確に記述でき、複数のインプットを持てるため、そのような煩雑さがない。
 
@@ -179,6 +180,7 @@
 
 AliceではTopologyManagerという機構が分散ノードを管理しており、静的・動的なトポロジーを自動構成する。静的トポロジーではプログラマがトポロジーを図として記述できるため、より分かりやすく詳細な設定ができる。
 
+\newpage
 
 \section{信頼性・拡張性の高い通信の提供}
 ここでは信頼性・拡張性の高い通信の指標として、障害耐性、圧縮・転送通信、NAT越えについてを比較する。
@@ -203,6 +205,8 @@
 Data Segment内に圧縮と非圧縮の両形式を同時に持てるため、受け取った圧縮データを展開をしながら圧縮したまま別ノードに転送することができる。
 また、圧縮するには送信する宛先ラベルに"compressed"とつけるだけでよく、データ取得時に自動で展開もされるため、プログラマがメソッドの呼び出しを追加する必要がなく圧縮・非圧縮を簡単に切り替えられる。
 
+\newpage
+
 \subsection*{NAT越え}
 ネットワーク間通信の大きな問題の一つに、NATがある。
 NATとは、WANとLANの間にあるIPアドレスの変換機構である。
@@ -481,8 +485,6 @@
 され接続処理が順次行われる。
 そしてTopology Managerが持つトポロジー情報が更新される。
 現在Topology Managerでは動的なトポロジータイプとして二分木に対応している。
-%TopologyNodeとnodenameの説明もう少し
-
 
 
 
@@ -490,19 +492,19 @@
 Aliceを拡張していく中でいくつかの問題点が明らかになり、これらを解決するにはAlice自体を再設計する必要があるとわかった。
 
 
-\section{直感的でないAPI}
-2.4で示したように、CSで使うDSをtake/peekのメソッドを直接は呼び出せない。%どこから？型とkeyの指定をしなければならず、それはcreate/setkeyでコンストラクタで指定しなくてはならない。直接呼び出せないわけではなく、分離されていてどこで記述するのかが決まっていない。
-%setKeyをkeyとTAKEorPEEKが記述が分離されてしまうのがややこしい、見通しが悪い。どこに書くか明確にすべき。
-%putしわすれも問題
-一度フィールドでReceiverをcreateして、その後Reveiverに対してsetKeyで待ち合わせるkeyを指定しなければならない。
-これでは手間がかかる上、コードを読んだ際にどのKeyに対して待ち合わせを行っているのか直感的に分からない。
-さらに、setKeyはそのDSを待ち合わせているCS以外からも呼び出せてしまう\ref{src:StartSetKey}。
+\section{APIの記述の分離}
+2.4で示したように、InputDSを記述するには、一度フィールドでReceiverをcreateして、その後Reveiverに対してsetKeyで待ち合わせるkeyを指定しなければならない。
+このようにインプットの処理が分離されてしまっていては、記述が煩雑な上にコードを読んだ際にどのkeyに対して待ち合わせを行っているのか直感的に分からない。
+
+さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう\ref{src:StartSetKey}。
 
     \lstinputlisting[label=src:StartSetKey, caption=setKeyを外部から呼び出す例]{source/StartSetKey.java}
     \lstinputlisting[label=src:SetKey]{source/SetKey.java}
 
-    このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。
-可読性の低いコードはプログラマの負担となるため、CSが何を待ち合わせているのかそのCSを見ただけで理解できるようにAPIを改善すべきである。
+このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。
+これでは見通しが悪いため、どこでkeyを指定するのか明確にすべきである。
+
+可読性の低いコードはプログラマの負担となるため、CSが何を待ち合わせているのかそのCSを見ただけで理解できるように記述の分離問題を改善しなくてはならない。
 
 
 \section{setKeyは最後に呼ばなければならない}
@@ -528,11 +530,10 @@
 \section{動的なsetKey}
 setKeyはCSのコンストラクタで指定することが多い。
 このとき、指定するkeyは引数などから動的に受け取り、セットすることができる。
-しかし、その使い方では、putする部分など、該当するkeyを扱う全てコードを変更しなければならない。
-現在のAliceではsetKeyが柔軟に使えるがために、慎重に書かなければプログラムの信頼性が保てない。
-そのため、動的なsetKeyはできないように制限したほうが良いと考える。
-%もっと強く。動的にやって性能おちることある？動的なsetKeyを使うと読みづらく何が起きているかわからないのでなくすべき
-%動的に書いたものを静的に変換可能。。。keyを介した通信
+しかし、それでは実際にどんな処理が行われているのかわかりづらく、また、putする部分などの該当するkeyを扱う全てコードを変更しなければならない。
+このように、AliceではCSを使いまわすことを考慮して動的なsetKeyを可能にしてしまったせいで、慎重に書かなければプログラムの信頼性が保てないようになってしまっている。
+そのため、動的なsetKeyはできないように制限し、コードの見通しを良くする必要がある。
+CSに対してインプットとなるkeyが静的に決まれば、待ち合わせているkeyに対してのputのし忘れなどの問題をコンパイル時のモデル検査などで発見することができると考えられる。
 
 \section{型が推測できない}
 inputDSを受け取るReceiverはデータをObject型で持っており、そのデータをCS内で扱うには正しい型にキャストする必要がある。
@@ -565,12 +566,11 @@
 そのために以下のような問題が発生した。
 
 \subsection{１つのノードで複数台DSM同士のテストが行えない}
-当研究室では分散データベースJungle\cite{}を開発しており、その分散通信部分にはAliceが用いられている。
+当研究室では分散データベースJungle\cite{Jungle}を開発しており、その分散通信部分にはAliceが用いられている。
 Jungleのような分散アプリケーションの開発では、１つのマシン上で複数の疑似ノードを立ててテストを行いたい場合があった。
 しかし、Aliceでは一つのアプリケーション内にLocalDSMは一つと決まっていたため、テストに必要なノード数分だけアプリケーションを別で立ち上げなければならないという手間があった。
 このためのシェルスクリプトをプログラマが書かなければならないのは本質的な作業ではない。
 より気軽にテストができるよう、同一プログラム内でLocalDSMを複数立ち上げられるようにすべきだと考えた。
-%TopologyManagerに2回接続できない
 
 \subsection{TopologyManagerの拡張が困難}
 Aliceではより自由度の高い通信を行うために、TopologyManagerに幾つかの機能を追加すること考えていた。
@@ -586,7 +586,6 @@
 \caption{複数のTopologyManagerによるNAT越えの実現}
 \label{fig:nat}
 \end{figure}
-%図がまちがってる
 \newpage
 
 また、別トポロジーで立ち上げたアプリケーション同士を接続する機能も追加したいと考えていた。
@@ -695,8 +694,9 @@
 \newpage
 
 \section{APIの改善}
-%この章でなにをするか
-\subsection{TAKE/PEEK}%アノテーションの導入。サブセクションにはしない
+ここではAliceのAPIの問題を踏まえて設計したChristieのAPIについて、インプット、アウトプット、データの取り出しに分けて説明する。
+
+\subsection*{アノテーションの導入によるインプットの記述}
 InputAPIにはAliceと同じくTakeとPeekを用意した。
 ChristieではInput DG の指定にはアノテーションを使う。
 アノテーションとは、クラスやメソッド、パッケージに対して付加情報を記述できるJavaのMeta Computationである。
@@ -710,7 +710,11 @@
 
 アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。
 これにはJavaのreflectionAPIを利用している。
-アノテーションの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。
+
+Christieのこのインプットアノテーションはフィールドに対してしか記述できないため、InputDGの生成とTake/Peekの指定とkeyの指定を必ず一箇所で書くことが明確に決まっている。
+そのためAliceのように外のCSからのkeyへの干渉をされることがない。
+また、アノテーションの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。
+このように、アノテーションを用いたことで、Aliceの記述の分離問題が解決された。
 
 \ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。
 DataGearは様々な型のデータを扱うためにJavaの総称型で受け取るようにしており、\textless \textgreater 内に指定した型でデータの型を限定できる。
@@ -727,7 +731,6 @@
 
 \lstinputlisting[label=src:remotetake, caption=RemoteTakeの例]{source/christie/RemoteInputDG.java}
 
-\newpage
 
 なお、圧縮のMeta ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける（\ref{src:compresslocal}）。
 
@@ -737,28 +740,28 @@
 しかし、Localでの圧縮をしようと思えばRemoteTakeを用いて間接的にすることは可能である。
 
 
-\subsection{PUT/FLIP}
+\subsection*{DGMを指定してのアウトプットの記述}
 OutputAPIにはput/flipを用意した。
 put/flipのメソッドはDGMに用意されている。
 cal.java
 CodeGear.classにはDGMを取得するメソッドがあり、それを用いて書き込みたいDGMを指定して直接putする。
-そのためLocal/Remoteの切り替えはDGMの切り替えによって行う。
+そのためLocal/Remoteの切り替えは指定するDGMの切り替えによって行う。
 ソースコード\ref{src:put}、\ref{src:remoteput}はLocalとRemoteにputする記述の例である。
 
 \lstinputlisting[label=src:put, caption=Localへputする例]{source/christie/Put.java}
 \lstinputlisting[label=src:remoteput, caption=Remoteへputする例]{source/christie/RemotePut.java}
 
+\newpage
+
 flipも同様にDGMに直接DGを渡す(\ref{src:flip})。
 
 \lstinputlisting[label=src:flip, caption=Remoteへflipする例]{source/christie/Flip.java}
 
-
 ChristieではDGMに対して直接putするため、AliceのODSにあたる部分はない。
 ODSを経由するより直接DGMに書き込むような記述のほうが直感的であると考えたためである。
 
-\newpage
 
-\subsection{getData()}
+\subsection*{型を指定しないデータの取り出し}
 AliceのasClassに相当するのがgetDataである。
 ソースコード\ref{src:getdata}はgetDataを用いてInputDGからデータを取得する例である。
 
@@ -769,7 +772,7 @@
 この型は内部で保存され、リモートノードと通信する際も保たれる。
 このようにgetDataするだけでプログラマが指定しなくとも正しい型で取得できるため、プログラマの負担を減らし信頼性を保証することができる。
 
-
+\newpage
 
 \section{CodeGearの記述方法}
 以下のコードはLocalDSMにputしたDGを取り出して表示するのを10回繰り返す例題である。
@@ -781,6 +784,8 @@
 StartCGはStartCodeGear.classを継承することで記述できる。
 AliceではStartCSもCodeSegment.classを継承して書かれていたため、どれがStartCSなのか判別しづらかったが、Christieではその心配はない。
 
+\newpage
+
 StartCGを記述する際にはcreateCGMメソッドでCGMを生成してコンストラクタに渡す必要がある。
 ソースコード\ref{src:StartCodeGear}の8行目でそれが行われている。
 createCGMの引数にはリモートノードとソケット通信する際使うポート番号を指定する。
@@ -883,7 +888,7 @@
 
 REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。
 
-
+\chapter{再設計への考察}
 
 \chapter{まとめ}
 
@@ -957,7 +962,7 @@
 
 また、本フレームワークの名前の由来となったクリスティー式戦車の生みの親、ジョン・W・クリスティーに敬意を評します。
 
-最後に、日々の研究生活を支えてくださった米須智子さん、菱田正和さん、情報工学科の方々、そして家族に心より感謝いたします。
+最後に、日々の研究生活を支えてくださった新里幸恵さん、大嶺志歩さん、阿波連知恵さん、米須智子さん、菱田正和さん、情報工学科の方々、そして家族に心より感謝いたします。
 
  
 %参考文献