--- a/Paper/chapter/1-Christie.tex	Sun Jan 09 22:45:03 2022 +0900
+++ b/Paper/chapter/1-Christie.tex	Wed Jan 26 23:07:23 2022 +0900
@@ -7,7 +7,7 @@
 データを受け取る際にObject型で受け取っているため、送信元を辿らない限り何の型が送信されているか不明瞭である。
 
 
-それらの問題点を解消するためにAliceを再設計され、作成されたものがChristieである。
+それらの問題点を解消するためにAliceを再設計し、作成されたものがChristieである。
 ChristieではAliceの機能や概念を維持しつつ、Aliceで発生していた問題点やプログラムを煩雑さなどを解消している。
 
 
@@ -66,10 +66,15 @@
 通常のRunnableクラスでは引数を受け取ることができないが、
 CodeGearExecutorというRunnableのMeta Computationを挟んだことでCGMを受け渡しながらの記述を可能にしている。
 
-
 DGMに対してput操作を行うことでDGM内のqueueにDGを保管できる。
 DGを取り出す際には、CG内で宣言した変数データにannotationを付ける。
-DGのannotationには以下の4種類がある。
+
+
+\section{annotationを使用したデータの記述}
+
+ChristieではDGの指定にannotationを使用する。 annotationとはクラスやメソッド、パッケージに対して付加情報を記述できる
+Java のMeta Computationである。先頭に@を付けることで記述でき、オリジナルのannotationを定義することもできる。
+Christieのannotationには以下の4種類がある。
 
 \begin{description}
   \item[Take] 先頭のDGを読み込み、そのDGを削除する。
@@ -78,10 +83,7 @@
   \item[PeekFrom(Remote DGM name)] Peekと処理動作は同じであるが、 Remote DGM nameを指定することで、その接続先(Remote)のDGMからPeek操作を行うことができる。 
 \end{description}
 
-\section{annotationを使用したデータの記述}
 
-ChristieではDGの指定にannotationを使用する。 annotationとはクラスやメソッド、パッケージに対して付加情報を記述できる
-Java のMeta Computationである。先頭に@を付けることで記述でき、オリジナルのアノテーションを定義することもできる。
 DGの宣言には型と変数を直接宣言し、変数名としてkeyを記述する。 そして、その宣言の上にannotationでTakeまたはPeekを指定する(ソースコード\ref{src:TakeExample})。
 
 
@@ -99,6 +101,72 @@
 \lstinputlisting[label=src:TakeFromExample, caption=TakeFromの例]{src/TakeFrom.java}
 
 
+\section{データの型整合性}
+Aliceでは送受信するデータはReceive型という専用の型を使用していた。
+内部のデータ自体はobject型だったため、元データの型を知るためには送信元を確認する必要があった。
+ChristieではannotationでDGの宣言を行っているため、直接変数の型を宣言することが可能となっている。
+ソースコード\ref{src:InputDGExample}はDGのデータを扱う例である。
+
+\lstinputlisting[label=src:InputDGExample, caption=DGのデータを扱う例]{src/InputDG.java}
+
+DGとして宣言した変数の型は、JavaのreflectionAPIを用いてCGMで保存され、LocalやRemoteノードと通信する際に適切な変換が行われれる。
+この様にプログラマが指定せずとも正しい型でデータを取得できるため、プログラマの負担を減らし信頼性を保証することができる。
+
+\newpage
+
+\section{CodeGearの記述方法}
+以下のソースコード\ref{src:StartCGExample}、\ref{src:CGExample}、\ref{src:CounteObj}はLocalDGMにputしたDGを取り出して表示し、
+インクリメントして10回繰り返す例題である。
+
+\lstinputlisting[label=src:StartCGExample, caption=StartCodeGearの記述例]{src/StartCGExample.java}
+\lstinputlisting[label=src:CGExample, caption=CodeGearの記述例]{src/CodeGearExample.java}
+\lstinputlisting[label=src:CounteObj, caption=DGとして送信されるオブジェクトのクラス]{src/CountObject.java}
+
+Chrisiteでは、StartCodeGear(以下StartCG)から処理を開始する。
+StartCGはStartCodeGear.javaを継承することで記述可能である。
+
+StartCGを記述する際には、createCGMメソッドによりCGMを生成する必要がある(ソースコード\ref{src:StartCGExample} 5行目)。
+createCGMの引数にはremoteノードとソケット通信をする際に使用するポート番号を指定する。
+CGMを生成した際にLocalDGMやremoteと通信を行うためのDaemonも生成される。
+
+
+CGに対してannotationから待ち合わせを実行する処理はsetupメソッドが行う。
+そのためソースコード\ref{src:StartCGExample}の6行目、ソースコード\ref{src:CGExample}の10行目のように、
+CGのインスタンスをCGMのsetupメソッドに渡す必要がある。
+そのためどこでもCGの待ち合わせを行うことができず、必ずCGMの生成を行う必要がある。
+その制約により、複雑になりがちな分散プログラミングのコードの可読性を高めている。
+実行されたCGを再度実行する場合にも、CGのインスタンスを生成してsetupメソッドに渡す。
+
+
+\section{DataGearManagerの複数立ち上げ}
+AliceではLocalDGMと同じ機能のLocalDataSegmentManagaer(以下LocalDSM)がstaticで実装されていたため、複数のLocalDSMを立ち上げることができなかった。
+しかしChristieではCGMの生成に伴いLocalDGMも生成されるため、複数作成が可能である。
+複数のLocalDGM同士のやり取りも、Remoteへの接続と同じ様に相手をRemoteDGMとしてproxyとして立ち上げることでアクセス可能である(図\ref{fig:LocalRemoteCommunication})。
+
+\begin{figure}[htb]
+  \begin{center}
+      \includegraphics[width=150mm]{images/LocalRemoteCommunication.pdf}
+  \end{center}
+  \caption{RemoteDGMを介したCGM間の通信}
+  \label{fig:LocalRemoteCommunication}
+\end{figure}
+
+\newpage
+
+ソースコード\ref{src:2LocalDGM}はLocalDGMを2つ立ち上げ、お互いをremoteに見立てて通信する例である。
+6行目にあるように、RemoteDGMを立ち上げるにはCGMが持つcreateRemoteDGMメソッドを用いる。
+引数にはRemoteDGM名と接続するremoteノードhost名、ポート番号を指定している。
+
+\lstinputlisting[label=src:2LocalDGM, caption=LocalDGMを2つ作る例]{src/RemoteDGMCommunication.java}
+
+remoteへの接続と同じ様にアクセスが可能になっており、コードを変更せずに同一マシン上の1つのアプリケーション内で分散アプリケーションのテストが可能となっている。
+
+
+また、CGMは内部に同一プロセス全てのCGMリストをstaticで持っており、複数生成したCGMを全て管理している。
+つまり、メタレベルではRemoteDGMを介さずに各LocalDGMに相互アクセス可能である。
 
 
 
+\section{通信フロー}
+
+