Mercurial > hg > Papers > 2016 > tatsuki-prosym

changeset 34:34ee004791a3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Modify
author tatsuki
date Wed, 30 Nov 2016 16:24:29 +0900
parents 388da5c83f48
children 6afc5049f8b6
files bbs.tex jungle.tex maTrix.tex renderingEngine.tex
diffstat 4 files changed, 108 insertions(+), 82 deletions(-) [+]
line wrap: on
line diff
--- a/bbs.tex	Tue Nov 29 22:15:00 2016 +0900
+++ b/bbs.tex	Wed Nov 30 16:24:29 2016 +0900
@@ -1,12 +1,12 @@
 \section{Jungle Tree ブラウザ}
 
-Jungleの木に対する変更において、JungleTreeEditorクラスを用いる方法はプログラム上では便利だが、手動で変更するのには向いていない。
+Jungleの木に対する変更において、{\tt JungleTreeEditor}クラスを用いる方法はプログラム上では便利だが、手動で変更するのには向いていない。
 よって、組み込みWEBサーバーであるJettyを使用し、Servletとして木の表示と編集を実現した。
 
 \subsection{木構造の表示}
 JungleTreeブラウザにおいて、Jungle DBはWEBサーバー内に存在し、それから表示に必要なHTMLを生成してブラウザに転送する。
 %図\ref{printNode}は、サーバからデータを送り、ブラウザ上でノードを可視化するまでの流れである。
-この流れは、JungleのNodePathの処理を除けば通常のデータベースのレコードの表示と同等である。
+この流れは、Jungleの{\tt NodePath}の処理を除けば通常のデータベースのレコードの表示と同等である。
 
 編集するノードのパスはURLで記述されている。例えば、
 {\small
@@ -19,20 +19,19 @@
 \begin{enumerate}
 \item ユーザーは表示したいノードのパスをURLでJungleTreeブラウザに送る。
 \item JungleTreeブラウザは、WEBサーバ内にあるJungleから、対応した木を取得する。
-\item JungleTreブラウザは、パスで指定した位置のノードを返す関数、{\tt tree.getNodeOfPath()}を用いて、木から表示するノードを取得する。
+\item JungleTreブラウザは、パスで指定した位置のノードを木から取得する。
 \item 取得したノードの中身を、JungleTreeブラウザが表示する。
 \end{enumerate}
 
 
-\subsection{ブラウザを使った木の編集}
+\subsection{Jungle Tree ブラウザを使った木の編集}
 %図\ref{JungleEdit}はブラウザを用いたJungleの木の更新の流れである。
-
+以下にJungle Treeブラウザを用いた木の編集の流れを示す。
 \begin{enumerate}
 \item ユーザーはJungleTreeブラウザで編集したいノードを表示するページに移動する 。
 \item ユーザーはJungleTreeブラウザに木の変更要求を送る。
 \item JungleTreeブラウザはWebサーバー内にあるJungleから、対応した木を取得する。
-\item 編集を行う木から、JungleTreeEditorクラスを取得する。
-\item JungleTreeEditorクラスを使用して木の変更を行う。
+\item 編集を行う木から、{\tt JungleTreeEditor}クラスを取得し、木の変更を行う。
 \item 木の変更をJungleにコミットする。
 \item 木の変更の結果を表示する。
 \end{enumerate}
--- a/jungle.tex	Tue Nov 29 22:15:00 2016 +0900
+++ b/jungle.tex	Wed Nov 30 16:24:29 2016 +0900
@@ -1,8 +1,8 @@
 \section{非破壊的木構造データベースJungle}
-Jungleは等研究室が開発を行っているデータベースで、Javaを用いて実装されている。
+Jungleは、当研究室が開発を行っているデータベースで、Javaを用いて実装されている。
 
 Jungleは名前付きの複数の木の集合からなり、木は複数のノードの集合で出来ている。
-ノードは自身の子のListと属性名と属性値の組でデータを持ち、データベースのレコードに相当する。
+ノードは自身の子のリストと属性名と属性値の組でデータを持ち、データベースのレコードに相当する。
 通常のレコードと異なるのは、ノードに子供となる複数のノードが付くところである。
 Jungleでは、親から子への片方向の参照しか持たない。
 
@@ -23,7 +23,8 @@
 \end{figure}
 
 \newpage
-通常のRDBと異なり、Jungleは木構造をそのまま読み込むことができる。例えば、XMLやJsonで記述された構造を、データベースを設計することなく読み込むことが可能であり、実際、そのような機能が実装されている。この木をそのままデータベースとして使用することも可能である。しかし、木の変更の手間は木の構造に依存する。
+通常のRDBと異なり、Jungleは木構造をそのまま読み込むことができる。例えば、XMLやJsonで記述された構造を、データベースを設計することなく読み込むことが可能である。
+この木を、そのままデータベースとして使用することも可能である。しかし、木の変更の手間は木の構造に依存する。
 %特に非破壊木構造を採用しているJungleでは木構造の変更にo(1)からo(n)の様々な選択肢がある。つまり、アプリケーションに合わせて木を設計しない限り、
 特に非破壊木構造を採用しているJungleでは、木構造の変更の手間はO(1)からO(n)となりえる。つまり、アプリケーションに合わせて木を設計しない限り、
 十分な性能を出すことはできない。逆に、正しい木の設計を行えば高速な処理が可能である。
@@ -35,7 +36,7 @@
 
 \subsection{木の生成}
 初めにJungleにおける木の生成について述べる。
-Jungleは複数の木を一意な名前を利用して管理しており、名前を利用することで作成、編集、削除を行う。
+Jungleは複数の木を、名前を利用して管理しており、名前を利用することで作成・編集・削除を行う。
 以下にJungleクラスが提供している木の生成・管理を行うAPI(表\ref{jungleAPI})を記す。
 \begin{table}[htb]
 \begin{center}
@@ -72,37 +73,37 @@
 \caption{Childrenに実装されているAPI}
 \begin{tabular}{|p{8em}|p{14em}|}                                  \hline
 {\tt int size()}  &  子供の数を返す。\\ \hline
-{\tt <Either Error,TreeNode> at(int num)} &ノードが持つ子供の中から、 変数numで指定された位置にある子どもを返す。   \\ \hline
+{\tt <Either Error,TreeNode> at(int num)} &ノードが持つ子供の中から、 変数{\tt num}で指定された位置にある子ノードを返す。   \\ \hline
 \end{tabular}
 \label{Children}
 \end{center}
 \end{table}
 
 
-関数{\tt children.at(int num)}が返す{\tt Either\textless Error,TreeNode\textgreater} オブジェクトは、{\tt isA() }でErrorかどうかをチェックすることができる。
-Errorでない場合は{\tt b()}でTreeNodeオブジェクトを取り出すことができる。
+関数{\tt children.at(int num)}が返す{\tt Either\textless Error,TreeNode\textgreater} オブジェクトは、{\tt isA() }で{\tt Error}かどうかをチェックすることができる。
+{\tt Error}でない場合は{\tt b()}で{\tt TreeNode}オブジェクトを取り出すことができる。
 
 
 \begin{table}[htbH]
 \begin{center}
 \caption{Attributeに実装されているAPI}
 \begin{tabular}{|p{10em}|p{12em}|} \hline
-ByteBuffer get(String key)   &ノードが持つ値から、属性名 keyとペアの属性値をByteBuffer型で返す。 \\ \hline
-String getString(String key) &ノードが持つ値から、属性名 key とペアの属性値をString型で返す。 \\ \hline
+{\tt ByteBuffer get(String key)}   &ノードが持つ値から、属性名 {\tt key}とペアの属性値を{\tt ByteBuffer}型で返す。 \\ \hline
+{\tt String getString(String key)} &ノードが持つ値から、属性名 {\tt key} とペアの属性値を{\tt String}型で返す。 \\ \hline
 \end{tabular}
 \label{Attribute}
 \end{center}
 \end{table}
 
  \newpage
-以下にルートノードの2番目の子供から、属性名 nameとペアになっている属性値を取得するサンプルコードを記述する。
+以下にルートノードの2番目の子供から、属性名 {\tt name}とペアになっている属性値を取得するサンプルコードを記述する。
 \begin{lstlisting}[frame=lrbt,numbers=left,label=getAttributeCode]
 JungleTree tree = jungle.getTreeByName("TreeName");
 TreeNode root = tree.getRootNode();
 Children children = root.getChildren();
 Either<Error,TreeNode> either = children.at(2);
 if (either.isA()) 
-    throw new IllegalStateException();
+    throw new IOException();
 TreeNode child = either.b();
 Attribute attribute = child.getAttribute();
 String value = attribute.getString("name");
@@ -111,20 +112,20 @@
 \begin{enumerate}
 \item Jungleから名前を指定して木を取得する。 
 \item 取得した木のルートノードを取得する。
-\item 木のルートノードからChildren型の子ノードを取得する。
+\item 木のルートノードから{\tt Children}型の子ノードを取得する。
 \item 変数{\tt children}から2番目の子供を取得する。
 \item 2番目の子供が取得できたかを調べる。
 \item 取得できていなかった場合{\tt Exception}を投げる。
 \item 取得に成功していた場合、{\tt either}から子ノードを受け取る。
-\item 取得した子ノードからAttributeクラスを取得する。
+\item 取得した子ノードから{\tt Attribute}クラスを取得する。
 \item 取得した{\tt attribute}から属性名 {\tt name}がペアの値を取得する。
 \end{enumerate}
 
 
 \subsection{NodePath}
-Jungleでは、木のノードの位置をNodePathクラスを使って表す。
-NodePathクラスはルートノードからスタートし、対象のノードまでの経路を、数字を用いて指し示すことで対象のノードの場所を表す。また、ルートノードは例外として-1と表記される。
-NodePathクラスが{\tt < -1,1,2,3>} を表している際の例を図\ref{NodePath}に記す。
+Jungleでは、木のノードの位置を{\tt NodePath}クラスを使って表す。
+{\tt NodePath}クラスはルートノードからスタートし、対象のノードまでの経路を、数字を用いて指し示すことで対象のノードの場所を表す。また、ルートノードは例外として-1と表記される。
+{\tt NodePath}クラスが{\tt < -1,1,2,3>} を表している際の例を図\ref{NodePath}に記す。
 \begin{figure}[h]
 \begin{center}
 \includegraphics[height = 6cm , bb=0 0 568 455]{images/nodePath.pdf}
@@ -138,8 +139,8 @@
 \newpage
 
 \subsection{木の編集API}
-Jungleの木の編集はJungleTreeEditorクラスを用いて行われる。
-JungleTreeEditorクラスには編集を行うために、表\ref{editor}で定義されているAPIが実装されている。
+Jungleの木の編集は{\tt JungleTreeEditor}クラスを用いて行われる。
+{\tt JungleTreeEditor}クラスには編集を行うために、表\ref{editor}で定義されているAPIが実装されている。
 
 \begin{table}[htb]
 \begin{center}
@@ -154,9 +155,9 @@
 {\tt Either< Error, JungleTreeEditor> deleteAttribute( NodePath path,String key)}&
 変数{\tt path}で指定した場所にあるノードが持つ、属性名 変数{\tt key}とペアで保存されているデータを削除する。\\ \hline
 {\tt Either<Error, JungleTreeEditor> moveChild( NodePath path,int num,String move)} &
-変数{\tt path}で指定した場所にある、ノードの変数numで指定された位置の子供を変数{\tt move}の方向に移動させる。 \\ \hline
+変数{\tt path}で指定した場所にある、ノードの変数{\tt num}で指定された位置の子供を変数{\tt move}の方向に移動させる。 \\ \hline
 {\tt Either<Error, JungleTreeEditor> pushPop()} &
-ルートノードの上に新しいルートノードを追加する線形のTree等を作る際に使用することで計算量をO(n)からO(1)にできる。\\ \hline
+ルートノードの上に新しいルートノードを追加する。線形の木を作る際に使用することで計算量をO(n)からO(1)にできる。\\ \hline
 {\tt Either<Error, JungleTreeEditor> success()}  &
 木へ行った変更をコミットする。自分が編集を行っていた間に、他のJungleTreeEditorクラスによって木が更新されていた場合、コミットは失敗する。 \\ \hline
 \end{tabular}
@@ -165,11 +166,11 @@
 \end{table}
 
 
-編集後に返されるJungleTreeEditorクラスは、編集後の木構造を保持しているため、編集前の木構造を保持しているJungleTreeEditorクラスとは別のオブジェクトである。
-編集を行った後は、関数{\tt editor.success()}で今までの編集をコミットすることができる。他のJungleTreeEditorクラスによって木が更新されていた場合はコミットは失敗し、{\tt success()}はErrorを返す。
+編集後に返される{\tt JungleTreeEditor}クラスは、編集後の木構造を保持しているため、編集前の木構造を保持している{\tt JungleTreeEditor}クラスとは別のオブジェクトである。
+編集を行った後は、関数{\tt editor.success()}で今までの編集をコミットすることができる。他の{\tt JungleTreeEditor}クラスによって木が更新されていた場合はコミットは失敗し、{\tt success()}は{\tt Error}を返す。
 その場合は、木の編集を最初からやり直す必要がある。
 
-以下にJungleTreeEditorクラスを用いて、木の編集を行うサンプルコードを記述する。
+以下に{\tt JungleTreeEditor}クラスを用いて、木の編集を行うサンプルコードを記述する。
 
 \begin{lstlisting}[frame=lrbt,numbers=left,label=editorCode]
 JungleTreeEditor editor = tree.getTreeEditor();
@@ -182,13 +183,13 @@
 \end{lstlisting}
 
 \begin{enumerate}
-\item 関数{\tt tree.getEditor()}で編集を行う木から、JungleTreeEditorクラスを取得する。 
-\item 次に変更するノードの場所を示す、NodePathクラスを作成する。
+\item 関数{\tt tree.getEditor()}で編集を行う木から、{\tt JungleTreeEditor}クラスを取得する。 
+\item 次に変更するノードの場所を示す、{\tt NodePath}クラスを作成する。
 \item 関数{\tt editor.addNewChildAt()}を用いて、変数{\tt path}で指定したノードの子供の0番目に子ノードを追加する。
-\item 返り値の変数{\tt either}がErrorクラスを保持していないか(編集に失敗していないか)を確認する。
-\item Errorクラスを保持していた場合Exceptionを投げる。
-\item 編集に成功していた場合、編集後のJungleTreeEditorクラスを取得する。
-\item 取得したJungleTreeEditorクラスを用いて木の変更をコミットする。
+\item 返り値の変数{\tt either}が{\tt Error}クラスを保持していないか(編集に失敗していないか)を確認する。
+\item {\tt Error}クラスを保持していた場合{\tt Exception}を投げる。
+\item 編集に成功していた場合、編集後木を持った、{\tt JungleTreeEditor}クラスを取得する。
+\item 取得した{\tt JungleTreeEditor}クラスを用いて木の変更をコミットする。
 \end{enumerate}
 
 これらのAPIにより、Jungleは木構造を格納、編集する機能を持っている。
--- a/maTrix.tex	Tue Nov 29 22:15:00 2016 +0900
+++ b/maTrix.tex	Wed Nov 30 16:24:29 2016 +0900
@@ -1,9 +1,9 @@
 \section{許認可管理アプリケーション\\maTrix}
-本章では、Jungle上に実際に企業で運用されている許認可管理アプリケーションmaTrixを実装し、Jungleにデータベースとしての表現力、機能の十分性、実用的な性能があるかについて実証実験を行なう。
+本章では、Jungle上に実際に企業で運用されている許認可管理アプリケーションmaTrixを実装し、Jungleにデータベースとしての表現力、機能の十分性、実用的な性能があるか実証実験を行なう。
 
-maTrixは、人物、役職、役割、権限、組織等の木構造のデータとポリシーファイルを持つ。maTrixの組織構造は、それぞれの木構造がidを用いた参照を行うことで表現される。また、maTrixは過去のアクセス要求を全て保存する。アクセス要求は当時の組織構造を参照しているため、過去の組織構造にアクセス可能にするため、組織構造は版管理されている。
+maTrixは、人物、役職、役割、権限、組織の木構造のデータとポリシーファイルを持つ。maTrixの組織構造は、それぞれの木構造がidを用いた参照を行うことで表現される。また、maTrixは過去のアクセス要求を全て保存する。アクセス要求は当時の組織構造を参照しているため、過去の組織構造にアクセス可能にするため、組織構造は版管理されている。
 
-ポリシーファイルは、データに対するアクセス要求が許可されるか否認されるかを判断するためのルールを誰が(Target)、何を(Resource)、どうできるか(Action)の3つの要素で記述されている。maTrixはアクセス要求に応じたポリシーファイルを参照することで許認可の判断を行う。
+ポリシーファイルは、データに対するアクセス要求が許可されるか否認されるかを判断するためのルールを、誰が(Target)、何を(Resource)、どうできるか(Action)の3つの要素で記述されている。maTrixはアクセス要求に応じたポリシーファイルを参照することで許認可の判断を行う。
 ポリシーファイルは組織構造中の人や役職をidを用いて参照している。つまり、ポリシーファイルを用いて許認可を下すためには、その人がどこの組織に所属して、その役割がどの権限を持っているかを返す検索が必要になる。
 本章ではmaTrixをJungle上に実装する際の問題点、解法について記述する。
 
@@ -20,11 +20,13 @@
 \end{figure}
 
 図\ref{fig:PersonTree}の人物Treeには、maTrixで使用される人物のデータが記述されている。
-属性名 {\tt element} 属性値 {\tt Persons}のデータを持つNode1は、人物Treeのルートノードである。このノードの下に各人物のデータが格納されている(図\ref{fig:PersonTree}では{\tt Node2}、{\tt Node3}が該当する)。
-{\tt Node2}、{\tt Node3}が持つ、属性名 {\tt element}、属性値 {\tt Person}の値は、{\tt Node2}、{\tt Node3}が人物のデータを持っていることを表す。
-また{\tt Node2}が持つ、属性名 {\tt Person-id}、属性値 {\tt p:1} はこのノードに記述された人物のmaTrix上でのIDを表す。
+人物Treeは、 ルートノードが、属性名 {\tt element} 属性値 {\tt Persons}の組のデータを持つ。図\ref{fig:PersonTree}では、{\tt Node1}がルートノードとなる。
+ルートノードの下には、各人物のデータが格納されている(図\ref{fig:PersonTree}では{\tt Node2}、{\tt Node3}が該当する)。
+属性名 {\tt element}、属性値 {\tt Person}の値は、この値を持つノードが人物のデータを持っていることを表す。
+属性名 {\tt Person-id}、属性値 {\tt p:1} はこのノードに記述された人物のmaTrix上でのIDを表す。
 他の役職、役割、権限といった木構造は、このIDを用いて参照を行うことで組織構造を構築する。
-{\tt Node2}、{\tt Node3}は子ノードに人物の名前、参照する他の木構造のId等のデータを持つが、今回は省略している。
+{\tt Node2}、{\tt Node3}は子ノードに人物の名前や、参照する他の木構造のId等のデータを持つが、今回は省略している。
+
 
 また、maTrixは自身のデータをXML形式で書き出すことが可能である。書き出したデータをJungleに格納するために汎用XMLReaderの実装も行った。
 
@@ -33,7 +35,7 @@
 % 木のノードにIDを割ふってIndexを用いて参照する
 Jungle上でのmaTrixの組織構造の表現は、木のノードにIdを割り振ってIndexを用いた参照で表現する。
 しかし、JungleにはIndexが無かったため、実装を行った。
-Jungleは、非破壊的木構造とういデータ構造上、過去の版の木構造を全て保持しているため、全ての版に独立したIndexが必要となる。
+Jungleは、非破壊的木構造というデータ構造上、過去の版の木構造を全て保持しているため、全ての版に独立したIndexが必要となる。
 そのため、前の版のIndexを破壊すること無く、Indexを更新する必要があった。
 既存のTreeMapでは、一度Indexの複製を行った後更新する必要があったため、Indexの更新オーダーがO(n)となっていた。
 よって、非破壊TreeMapを自作し、それを用いてIndexの実装を行った。
@@ -47,46 +49,69 @@
   List<TreeNode> node> index> indexMap
 \end{lstlisting}
 
-JungleのIndexはIndexMap内に保持されている。
-属性名でIndexMapにgetを行うと、対応したIndexが取得できる。
-その取得したIndexに属性値で検索を行うと、対応したノードのリストが返ってくる。
+JungleのIndexは{\tt IndexMap}内に保持されている。
+属性名で{\tt IndexMap}に{\tt get}を行うと、対応したIndexが取得できる。
+取得したIndexに属性値で{\tt get}を行うと、ノードのリストが返ってくる。
+
+以下にIndexから属性名 name 属性値 kanagawaのデータを持つ、ノードのIteratorを取得するサンプルコードを記述する。
+
+\begin{lstlisting}[frame=lrbt,label=find,numbers=left]
+Optional<TreeMap<String, List<TreeNode>>> indexOp = indexMap.get("name");
+if (!indexOp.isPresent())
+  return new NulIterator<TreeNode>();
+TreeMap<String, List<TreeNode>> index = indexOp.get();
+Optional<List<TreeNode>> nodeListOp = index.get("kanagawa");
+if (!nodeListOp.isPresent())
+  return new NulIterator<TreeNode>();
+return nodeListOp.get().iterator();
+\end{lstlisting}
+
+\begin{enumerate}
+\item {\tt indexMap}に、今回検索で使用する属性名 {\tt name}を使用して{\tt get("name")}を行う。すると属性名 {\tt name}に対応したIndexが、{\tt Optional}クラスで包まれて返ってくる。
+
+\item {\tt Optional}オブジェクトに対して、中身を保持しているか(属性名 {\tt name}に対応したIndexをJungleが持っているか)を調べる。
+
+\item 持っていなかった場合、空の{\tt Iterator}オブジェクトを返す。
+
+\item 持っていた場合、{\tt Optional}オブジェクトからIndexを取得する。 
+ 
+\item 取得したIndexに、検索で使用する属性値{\tt kanagawa}で{\tt get()}を行う。属性名 {\tt name} 属性値{\tt  kanagawa}の値を持つノードのリストが、{\tt Optional}クラスに包まれて返ってくる。
+
+\item {\tt Optional}オブジェクトに対して中身を保持しているか(属性名 {\tt name} 属性値 {\tt kanagawa}を持つノードをJungleが持っているか)を調べる。
+
+\item 持っていなかった場合、空の{\tt Iterator}オブジェクトを返す。
+
+\item 持っていた場合{\tt Optional}オブジェクトからノードリストの{\tt Iterator}を返す。
+
+\end{enumerate}
 
 
 \subsection{検索APIの実装}
 Indexを実装したことにより、Idを用いた組織構造の表現は可能になった。
-しかし、組織構造に対する問い合わせを行うための検索APIが実装されていなかったため、属性名 {\tt key} 属性値 {\tt value}の組で検索を行うAPIの実装を、木の走査を行うTraverserクラス内に、lambda式を用いて行った。
-以下に検索を行う関数findの定義を記述する。
+しかし、組織構造に問い合わせを行う検索APIが実装されていなかったため、属性名 {\tt key} 属性値 {\tt value}の組で検索を行うAPIの実装を、木の走査を行う{\tt Traverser}クラス内に、lambda式を用いて行った。
+以下に検索を行う関数{\tt find}の定義を記述する。
 \begin{lstlisting}[frame=lrbt,label=query,numbers=left]
 public Iterator<TreeNode> find(Query query, 
                String key, String searchValue);
 \end{lstlisting}
-
-関数{\tt find}は引数に、{\tt Query query}、{\tt String key}、{\tt String value}の3つの引数を取り、条件に一致したノードのIteratorインタフェースを返す。
+関数{\tt find}は引数に、{\tt Query query}、{\tt String key}、{\tt String value}の3つの引数を取り、条件に一致したノードの{\tt Iterator}インタフェースを返す。
 第1引数には、探索の条件を記述する関数{\tt boolean comdition(TreeNode)}を定義した{\tt Interface Query}を。
 第2、第3引数の、{\tt String key、String value}はIndexを用いた絞込みに使用する。{\tt 関数find}の使用例を以下に記す
 
 \begin{lstlisting}[frame=lrbt,label=find,numbers=left]
-InterfaceTraverser traverser 
-= tree.getTraverser(true);
-Iterator<TreeNode> resultNodeIterator 
-= traverser.find((TreeNode node) -> {
-    String personId = 
-    node.getAttributes().getString("Personid");
-    if (personId == null)
-      return false;
-    if (personId.equals("p:2"))
-      return true;
-    return false;
-    }, "element", "Person");
+InterfaceTraverser traverser = tree.getTraverser(true);
+Iterator<TreeNode> resultNodeIterator = traverser.find((TreeNode node) -> {
+  String personId = node.getAttributes().getString("Personid");
+  if (personId == null) return false;
+  return personId.equals("p:2");
+}, "element", "Person");
 \end{lstlisting}
 
 上記コードについて解説する。
 \begin{enumerate}
-\item 木の走査を行うTraverserクラスを取得する。
+\item 木の走査を行う{\tt Traverser}クラスを取得する。
 
-\item Indexから{\tt find}の第2、第3引数である、属性名 {\tt element}、属性値 {\tt Person}の組のデータを持つノードを取得する。
-
-\item 取得したノードを第1引数のQueryに渡す。
+\item Indexから{\tt find}の第2、第3引数である、属性名 {\tt element}、属性値 {\tt Person}の組のデータを持つノードを取得し、Queryに渡す。
 
 \item 引数のノードから関数{\tt getAttributes().getString("Personid")}で属性名 {\tt Personid}とペアになっている属性値を取得する。
 
--- a/renderingEngine.tex	Tue Nov 29 22:15:00 2016 +0900
+++ b/renderingEngine.tex	Wed Nov 30 16:24:29 2016 +0900
@@ -1,7 +1,8 @@
 \section{HTML Rendering Engine}
 前章でJungle上にmaTrixを実装し、性能評価を行うことで、Jungleに実用データベースたる表現力、性能があることが確認できた。
-本章ではにJungle上に例題アプリケーションとしてHTML Rendering Engineの開発を行い、その際に発生した問題、解法について解説する。
-HtmlRenderingEngineは、出力するデータが記述されたContents Tree、出力する形式が記述されたLayout Treeの2つの木構造を持ち、これらを参照しながらhtmlのレンダリングを行う。
+
+本章ではJungle上に例題アプリケーションとしてHTML Rendering Engineの開発を行い、その際に発生した問題、解法について解説する。
+HTMLRenderingEngineは、出力するデータが記述されたContents Tree、出力する形式が記述されたLayout Treeの2つの木構造を持ち、これらを参照しながらhtmlのレンダリングを行う。
 またレンダリングする例題は日記を選択した。
 
 \subsection{Contents TreeのJungle上での表現}
@@ -16,8 +17,8 @@
 \end{figure}
 
 
-RootNodeはContentの{\tt title}、日時、レンダリングする時に参照するLayout名を持つ。
-そして子ノードがContentsの本文等のデータを持つ。
+RootNodeはContentの{\tt title}、日時、レンダリングする時に参照するLayoutTreeのNodeNameを持つ。
+そして子ノードが日記の本文等のデータを持つ。
 表\ref{NodeAttribute}にノードが保持しているContentsの一覧を記述する。
 
 \begin{table}[htb]
@@ -25,9 +26,11 @@
     \caption{ノードが保持しているContents一覧}
     \begin{tabular}{|p{8em}|p{12em}|}        \hline
       属性名         & 属性値                             \\ \hline 
+      component      & レンダリングする際に参照するLayoutTreeのNodeName  \\ \hline
       title          & 日記のタイトル                      \\ \hline 
       date(rootNode) & 日記の日時                          \\ \hline 
       type           & そのノードが保持しているContextType。 text(日記本文) or image(画像データ)  \\ \hline
+      body           & 日記の本文                           \\ \hline
       date(image)    & 画像の保存日時                       \\ \hline
       fileName       & 画像の名前                           \\ \hline
     \end{tabular}
@@ -56,7 +59,7 @@
 \caption{LayoutTreeの主要な要素}
 \begin{tabular}{|p{8em}|p{12em}|}        \hline
 属性名              & 属性値                     \\ \hline 
-NodeName            &ノードの名前。ノード同士の参照時に用いられる。\\ \hline
+NodeName            &ノードの名前。ノード同士の参照時に用いられる。例外としてルートノードだけはdisplayinformationという名前を持つ\\ \hline
 displayComponent    &参照するノードの名前。          \\
 Name                &この属性名で取得できる値を持つNodeNameを持つノードを参照する。\\ \hline 
 use                 &このノードが、どのContentsに対してのLayoutを持つかを記述するタグ。表\ref{tag}にタグとContentsの対応を記述する。\\ \hline
@@ -69,8 +72,8 @@
 
 Layout Treeは、ルートノードに属性名 {\tt NodeName} 属性値 {\tt displayinformation} の値を持つ(図\ref{layoutTree}では{\tt Node1}が該当する)。
 ルートノードは、子ノードに複数のComponentを保持する(図\ref{layoutTree}では{\tt Node2}、{\tt Node3}がそれに該当する)。
-{\tt Node2}は、{\tt "use" = "image"}のペアでタグを保持しているため、Contents Treeの日記の画像表示に対応する記述が行われている。
-{\tt Node3}は、{\tt "use" = "text"}のペアでタグを保持しているため、Contents Treeの日記の本文に対応する記述が行われている。
+{\tt Node2}は、属性名 {\tt use} 属性値 {\tt image}のペアでタグを保持しているため、日記の画像表示に対応する記述が行われている。
+{\tt Node3}は、属性名 {\tt use} 属性値 {\tt text}のペアでタグを保持しているため、日記の本文に対応する記述が行われている。
 表\ref{tag}にタグとContentsの対応を記述する。
 
 \begin{table}[htb]
@@ -103,19 +106,18 @@
 
 以下に図\ref{contentTree}のContentsTree、図\ref{multiComponent}のLayoutTreeの２つを使用した、レンダリングの流れを記述する。
 \begin{enumerate}
-\item ContentsTreeのルートノードは、属性名 {\tt component} 属性値 {\tt Multi@Component}の組を持つ。よって今回はLayoutTreeの、NodeNameが{\tt Multi@Component}のノードに記述されたルールに則ってレンダリング。
 
-\item ContentTreeは、属性名 {\tt component} 属性値 {\tt Multi@Component}の組を持つノード、つまり{\tt Node2}を参照する。
+\item  ContentsTreeのルートノードは、属性名 {\tt component} 属性値 {\tt Multi@Component}の組を持つので、LayoutTreeの{\tt Node2}を参照する。
 
-\item {\tt Node2}はこれ以上データを持たないので、子ノードである{\tt Node3、Node4}に記述されているデータの参照を行う。
+\item {\tt Node2}は自身のNodeNameしか持たないので、子ノードである{\tt Node3、Node4}に記述されているデータの参照を行う。
 
-\item {\tt Node3}は属性名 {\tt displayComponentName} 属性名 {\tt dialyImage@Component}の組を持つため、NodeNameが{\tt dialyImage@Component}のノードを参照する。
+\item {\tt Node3}は属性名 {\tt displayComponentName} 属性名 {\tt dialyImage@Component}の組を持つため、NodeNameが{\tt dialyImage@Component}のノードを参照している。
 
 \item レンダリングエンジンは、参照先のノードに記述されたルールに則ってHtmlを生成する。
 
 \item {\tt Node3}は、これ以上データを持たないため、次は{\tt Node4}を参照する。
 
-\item {\tt Node4}は属性名 {\tt displayComponentName} 属性名 {\tt dialyText@Component}の組を持つため、NodeNameが{\tt dialyText@Component}のノードを参照する。
+\item {\tt Node4}は属性名 {\tt displayComponentName} 属性名 {\tt dialyText@Component}の組を持つため、NodeNameが{\tt dialyText@Component}のノードを参照している。
 
 \item レンダリングエンジンは、参照先のノードに記述されているルールに則ってhtmlを生成する。
 
@@ -182,6 +184,5 @@
 %\end{flushleft}
 %\end{figure}
 
-測定結果より、Jungleデータベースはデータの設計を行うこと無く格納可能だが、設計を行ったほうがプログラム内のデータ構造とギャップがなく、高速に動作するプログラムを簡潔に記述できるようになる。
-測定結果より、１つのノードにデータを記述したほうが、ノードをたどる必要が無いので、プログラムは高速に動作する。
-しかし、\ref{mulitLayoutTree}のように複数のノードを用いることで簡潔にコードを記述できる例もあるので、コードの簡潔さと速度を両立した設計を行う必要がある。
+測定結果より、Jungleデータベースは、設計を行ったほうがプログラム内のデータ構造とギャップがなく、高速に動作するプログラムを簡潔に記述できるようになる。
+しかし、\ref{mulitLayoutTree}のように複数のノードにデータを分散させたほうが簡潔にコードを記述できる例もあるので、コードの簡潔さと速度を両立した設計を行う必要がある。