--- a/renderingEngine.tex	Tue Nov 29 17:33:47 2016 +0900
+++ b/renderingEngine.tex	Tue Nov 29 17:34:48 2016 +0900
@@ -113,9 +113,9 @@
 
 以下に図\ref{contentTree}のContentsTree、図\ref{multiComponent}のLayoutTreeの２つを使用した、レンダリングの流れを記述する。
 \begin{enumerate}
-\item ContentsTreeのルートノードは、属性名 component 属性値 Multi@Componentの組を持つ。よって今回はLayoutTreeの、NodeNameがMulti@Componentのノードに記述されたルールに則ってレンダリングを行う。
+\item ContentsTreeのルートノードは、属性名 component 属性値 Multi@Componentの組を持つ。よって今回はLayoutTreeの、NodeNameがMulti@Componentのノードに記述されたルールに則ってレンダリング。
 
-\item ContentTreeは、属性名 NodeName 属性値 Multi@Componentの組を持つノード、つまりNode2を参照する。
+\item ContentTreeは、属性名 component 属性値 Multi@Componentの組を持つノード、つまりNode2を参照する。
 
 \item Node2はこれ以上データを持たないので、子ノードであるNode3、Node4に記述されているデータの参照を行う。
 
@@ -156,13 +156,13 @@
 \end{figure}
 
 
-図\ref{goodLayoutTree}は、１つのノードにレンダリングに必要な値が全て格納されている。
-そのため、レンダリングを行う際、複数のノードをまたぐ必要が無く、簡潔にコードを書くことができる。
+図\ref{goodLayoutTree}のTreeは、１つのNodeにRenderingに必要な値が全て格納されている。
+そのため、Renderingを行う際、複数のNodeをまたぐ必要が無く、簡潔にコードを書くことができる。
 
 
 
-一方、図\ref{badLayoutTree}はレンダリングする際に、必要な値が複数のノードに分散されて保存されている。
-そのため、全てのノードを参照し、値を集める処理を行う必要があり、コードの可読性が下がり余計な処理も増えてしまった。
+一方、図\ref{badLayoutTree}のTreeはRenderingする際に必要な値が複数Nodeに分散されて保存されている。
+そのため、全てのNodeを参照し、値を集める処理を行う必要があり、コードの可読性が下がり余計な処理も増えてしまった。
 
 
 \subsection{性能評価}
@@ -193,4 +193,5 @@
 %\end{figure}
 
 測定結果より、Jungleデータベースはデータの設計を行うこと無く格納可能だが、設計を行ったほうがプログラム内のデータ構造とギャップがなく、高速に動作するプログラムを簡潔に記述できるようになる。
+測定結果より、１つのノードにデータを記述したほうが、ノードをたどる必要が無いので、プログラムは高速に動作する。
 しかし、\ref{mulitLayoutTree}のように複数のノードを用いることで簡潔にコードを記述できる例もあるので、コードの簡潔さと速度を両立した設計を行う必要がある。