--- a/paper/nozomi-master.tex	Sun Feb 04 16:13:57 2018 +0900
+++ b/paper/nozomi-master.tex	Sun Feb 04 17:25:00 2018 +0900
@@ -436,7 +436,9 @@
 
 
 \section{直感的でないAPI}
-2.4で示したように、CSで使うDSをtake/peekのメソッドを直接は呼び出せない。
+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}。
@@ -474,7 +476,8 @@
 しかし、その使い方では、putする部分など、該当するkeyを扱う全てコードを変更しなければならない。
 現在のAliceではsetKeyが柔軟に使えるがために、慎重に書かなければプログラムの信頼性が保てない。
 そのため、動的なsetKeyはできないように制限したほうが良いと考える。
-
+%もっと強く。動的にやって性能おちることある？動的なsetKeyを使うと読みづらく何が起きているかわからないのでなくすべき
+%動的に書いたものを静的に変換可能。。。keyを介した通信
 
 \section{型が推測できない}
 inputDSを受け取るReceiverはデータをObject型で持っており、そのデータをCS内で扱うには正しい型にキャストする必要がある。
@@ -490,7 +493,7 @@
 もしプログラマが適当に命名してしまえば後々混乱を招くため、待ち合わせるkey名とinput DS の変数名一致を強制させたい。
 
 
-\section{DataSegmentの明瞭性}
+\section{DataSegmentの型の明瞭性}
 2.5.1で示したように、Aliceに圧縮のMeta Computationを実装した際、DS内に複数の型を同時に持たせるようにした。
 
 
@@ -512,6 +515,7 @@
 しかし、Aliceでは一つのアプリケーション内にLocalDSMは一つと決まっていたため、テストに必要なノード数分だけアプリケーションを別で立ち上げなければならないという手間があった。
 このためのシェルスクリプトをプログラマが書かなければならないのは本質的な作業ではない。
 より気軽にテストができるよう、同一プログラム内でLocalDSMを複数立ち上げられるようにすべきだと考えた。
+%TopologyManagerに2回接続できない
 
 \subsection{TopologyManagerの拡張が困難}
 Aliceではより自由度の高い通信を行うために、TopologyManagerに幾つかの機能を追加すること考えていた。
@@ -527,7 +531,7 @@
 \caption{複数のTopologyManagerによるNAT越えの実現}
 \label{fig:nat}
 \end{figure}
-
+%図がまちがってる
 \newpage
 
 また、別トポロジーで立ち上げたアプリケーション同士を接続する機能も追加したいと考えていた。
@@ -636,7 +640,8 @@
 \newpage
 
 \section{APIの改善}
-\subsection{TAKE/PEEK}
+%この章でなにをするか
+\subsection{TAKE/PEEK}%アノテーションの導入。サブセクションにはしない
 InputAPIにはAliceと同じくTakeとPeekを用意した。
 ChristieではInput DG の指定にはアノテーションを使う。
 アノテーションとは、クラスやメソッド、パッケージに対して付加情報を記述できるJavaのMeta Computationである。