Mercurial > hg > Papers > 2016 > tatsuki-prosym
changeset 33:388da5c83f48
change table
| author | tatsuki |
|---|---|
| date | Tue, 29 Nov 2016 22:15:00 +0900 |
| parents | 8512227869d5 |
| children | 34ee004791a3 |
| files | bbs.tex introduction.tex jungle.tex maTrix.tex renderingEngine.tex |
| diffstat | 5 files changed, 84 insertions(+), 122 deletions(-) [+] |
line wrap: on
line diff
--- a/bbs.tex Tue Nov 29 19:52:37 2016 +0900 +++ b/bbs.tex Tue Nov 29 22:15:00 2016 +0900 @@ -14,10 +14,12 @@ \verb! bname=Layout&path=-1,0,2! } などとなる。 + +以下にJungleTreeブラウザを用いて、ノードを表示するまでの流れを記述する。 \begin{enumerate} \item ユーザーは表示したいノードのパスをURLでJungleTreeブラウザに送る。 \item JungleTreeブラウザは、WEBサーバ内にあるJungleから、対応した木を取得する。 -\item JungleTreブラウザは、パスで指定した位置のノードを返す関数、tree.getNodeOfPath()を用いて、木から表示するノードを取得する。 +\item JungleTreブラウザは、パスで指定した位置のノードを返す関数、{\tt tree.getNodeOfPath()}を用いて、木から表示するノードを取得する。 \item 取得したノードの中身を、JungleTreeブラウザが表示する。 \end{enumerate}
--- a/introduction.tex Tue Nov 29 19:52:37 2016 +0900 +++ b/introduction.tex Tue Nov 29 22:15:00 2016 +0900 @@ -1,5 +1,3 @@ - - \section{Jungle DBによるインピーダンスミスマッチの解決} プログラム中のデータ構造とRDBの表構造には大きなギャップがある。これはインピーダンスミスマッチと呼ばれている。 例えばRPGゲーム中のユーザが持つアイテムという単純なものでも、RDBではユーザとアイテムの組をキーとする巨大な表として管理することになる。
--- a/jungle.tex Tue Nov 29 19:52:37 2016 +0900 +++ b/jungle.tex Tue Nov 29 22:15:00 2016 +0900 @@ -40,12 +40,9 @@ \begin{table}[htb] \begin{center} \caption{Jungleに実装されているAPI} -\begin{tabular}{|l|l|} \hline -{\tt JungleTree createNewTree(String treeName) } & -Jungleに新しく木を生成する。木の名前が重複した場合、生成に失敗しnullを返す。 \\ \hline -{\tt -JungleTree getTreeByName(String treeName)} & - JungleからtreeNameと名前が一致するtreeを取得する。名前が一致するTreeがない場合取得は失敗しnullを返す \\ \hline +\begin{tabular}{|p{12em}|p{12em}|} \hline +{\tt JungleTree createNewTree(String treeName) } & Jungleに新しく木を生成する。木の名前が重複した場合、生成に失敗しnullを返す。 \\ \hline +{\tt JungleTree getTreeByName(String treeName)} & JungleからtreeNameと名前が一致するtreeを取得する。名前が一致するTreeがない場合取得は失敗しnullを返す \\ \hline \end{tabular} \label{jungleAPI} \end{center} @@ -60,11 +57,9 @@ \begin{table}[htb] \begin{center} \caption{TreeNodeに実装されているAPI} -\begin{tabular}{|l|l|} \hline -Children &ノードの子供を扱う \\ -getChildren() &Childrenオブジェクトを返す。 \\ \hline -Attribute &ノードが保持しているデータを \\ -getAttribute() &扱うAttribteオブジェクトを返す。 \\ \hline +\begin{tabular}{|p{8em}|p{14em}|} \hline +{\tt Children getChildren()} & ノードの子供を扱うChildrenオブジェクトを返す。\\ \hline +{\tt Attribute getAttribute()} &ノードが保持しているデータを扱うAttribteオブジェクトを返す。 \\ \hline \end{tabular} \label{TreeNodeAPI} \end{center} @@ -75,31 +70,25 @@ \begin{table}[htbH] \begin{center} \caption{Childrenに実装されているAPI} -\begin{tabular}{|l|l|} \hline -int size() &子供の数を返す。 \\ \hline -Either &ノードが持つ子供の中から、 \\ -\textless Error,TreeNode\textgreater &変数numで指定された \\ -at(int num) &位置にある子どもを返す。 \\ \hline +\begin{tabular}{|p{8em}|p{14em}|} \hline +{\tt int size()} & 子供の数を返す。\\ \hline +{\tt <Either Error,TreeNode> at(int num)} &ノードが持つ子供の中から、 変数numで指定された位置にある子どもを返す。 \\ \hline \end{tabular} \label{Children} \end{center} \end{table} -関数{\tt children.at(int num)}が返すEither\textless Error,TreeNode\textgreater オブジェクトは、{\tt isA() }でErrorかどうかをチェックすることができる。 +関数{\tt children.at(int num)}が返す{\tt Either\textless Error,TreeNode\textgreater} オブジェクトは、{\tt isA() }でErrorかどうかをチェックすることができる。 Errorでない場合は{\tt b()}でTreeNodeオブジェクトを取り出すことができる。 \begin{table}[htbH] \begin{center} \caption{Attributeに実装されているAPI} -\begin{tabular}{|l|l|} \hline -ByteBuffer &ノードが持つ値から、 \\ -get(String key) &属性名 keyとペアの属性値 \\ - &をByteBuffer型で返す。 \\ \hline -String &ノードが持つ値から、\\ -getString(String key) &属性名 key とペアの属性値 \\ - &をString型で返す。 \\ \hline +\begin{tabular}{|p{10em}|p{12em}|} \hline +ByteBuffer get(String key) &ノードが持つ値から、属性名 keyとペアの属性値をByteBuffer型で返す。 \\ \hline +String getString(String key) &ノードが持つ値から、属性名 key とペアの属性値をString型で返す。 \\ \hline \end{tabular} \label{Attribute} \end{center} @@ -126,16 +115,16 @@ \item 変数{\tt children}から2番目の子供を取得する。 \item 2番目の子供が取得できたかを調べる。 \item 取得できていなかった場合{\tt Exception}を投げる。 -\item 取得に成功していた場合、eitherから子ノードを受け取る。 -\item 取得した子ノードからAttributeを取得する。 -\item 取得したAttributeから属性名 nameがペアの値を取得する。 +\item 取得に成功していた場合、{\tt either}から子ノードを受け取る。 +\item 取得した子ノードからAttributeクラスを取得する。 +\item 取得した{\tt attribute}から属性名 {\tt name}がペアの値を取得する。 \end{enumerate} \subsection{NodePath} Jungleでは、木のノードの位置をNodePathクラスを使って表す。 NodePathクラスはルートノードからスタートし、対象のノードまでの経路を、数字を用いて指し示すことで対象のノードの場所を表す。また、ルートノードは例外として-1と表記される。 -NodePathクラスが\textless -1,1,2,3\textgreater を表している際の例を図\ref{NodePath}に記す。 +NodePathクラスが{\tt < -1,1,2,3>} を表している際の例を図\ref{NodePath}に記す。 \begin{figure}[h] \begin{center} \includegraphics[height = 6cm , bb=0 0 568 455]{images/nodePath.pdf} @@ -152,50 +141,32 @@ Jungleの木の編集はJungleTreeEditorクラスを用いて行われる。 JungleTreeEditorクラスには編集を行うために、表\ref{editor}で定義されているAPIが実装されている。 -\begin{table*}[htb] +\begin{table}[htb] \begin{center} \caption{Editorに実装されているAPI} -\begin{tabular}{|l|l|} \hline -Either &変数pathで指定した場所 \\ -\textless Error,JungleTreeEditor\textgreater &にある、ノードの子供の \\ -addNewChildAt( &変数posで指定した位置に\\ -NodePath path, &子ノードを追加する。 \\ -int pos) & \\ \hline -Either &変数pathで指定した場所 \\ -\textless Error,JungleTreeEditor\textgreater &にある、ノードの子供の \\ -deleteChildAt( &変数posで指定した位置の\\ -NodePath path, &子ノードを削除する。 \\ -int pos) & \\ \hline -Either &変数pathで指定した場所 \\ -\textless Error,JungleTreeEditor\textgreater &にあるノードに、 \\ -putAttribute( &属性名 変数key \\ -NodePath path, &属性値 変数valu \\ -String key, &のペアで値を挿入する。 \\ -ByteBuffer value) & \\ \hline -Either &変数pathで指定した場所 \\ -\textless Error,JungleTreeEditor\textgreater &にあるノードが持つ、 \\ -deleteAttribute( &属性名 変数keyとペアで \\ -NodePath path, &保存されているデータを \\ -String key) &削除する。 \\ \hline -Either &変数pathで指定した場所 \\ -\textless Error,JungleTreeEditor\textgreater &にある、ノードの変数num\\ -moveChild( &で指定された位置の子供を\\ -NodePath path &変数moveの方向に\\ -,int num, &移動させる。 \\ -String move) & \\ \hline -Either &ルートノードの上に新しい\\ -\textless Error,JungleTreeEditor\textgreater &ルートノードを追加する\\ -pushPop() &線形のTree等を作る際に\\ - &使用することで計算量を\\ - &O(n)からO(1)にできる。\\ \hline +\begin{tabular}{|p{8em}|p{14em}|} \hline +{\tt Either<Error, JungleTreeEditor> addNewChildAt( NodePath path, int pos)} & +変数{\tt path}で指定した場所にある、ノードの子供の変数{\tt pos}で指定した位置子ノードを追加する\\ \hline +{\tt Either<Error, JungleTreeEditor> deleteChildAt( NodePath path,int pos)} & +変数{\tt path}で指定した場所にある、ノードの子供の変数{\tt pos}で指定した位置の子ノードを削除する。 \\ \hline +{\tt Either<Error, JungleTreeEditor> putAttribute( NodePath path,String key,ByteBuffer value)} & +変数{\tt path}で指定した場所にあるノードに、属性名 変数{\tt key} 属性値 変数{\tt value} のペアで値を挿入する。 \\ \hline +{\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 Either<Error, JungleTreeEditor> pushPop()} & +ルートノードの上に新しいルートノードを追加する線形のTree等を作る際に使用することで計算量をO(n)からO(1)にできる。\\ \hline +{\tt Either<Error, JungleTreeEditor> success()} & +木へ行った変更をコミットする。自分が編集を行っていた間に、他のJungleTreeEditorクラスによって木が更新されていた場合、コミットは失敗する。 \\ \hline \end{tabular} \label{editor} \end{center} -\end{table*} +\end{table} 編集後に返されるJungleTreeEditorクラスは、編集後の木構造を保持しているため、編集前の木構造を保持しているJungleTreeEditorクラスとは別のオブジェクトである。 -編集を行った後は、関数editor.success()で今までの編集をコミットすることができる。他のJungleTreeEditorクラスによって木が更新されていた場合はコミットは失敗し、{\tt success()}は{\tt Error}を返す。 +編集を行った後は、関数{\tt editor.success()}で今までの編集をコミットすることができる。他のJungleTreeEditorクラスによって木が更新されていた場合はコミットは失敗し、{\tt success()}はErrorを返す。 その場合は、木の編集を最初からやり直す必要がある。 以下にJungleTreeEditorクラスを用いて、木の編集を行うサンプルコードを記述する。 @@ -211,10 +182,10 @@ \end{lstlisting} \begin{enumerate} -\item 関数tree.getEditor()で編集を行う木から、JungleTreeEditorクラスを取得する。 +\item 関数{\tt tree.getEditor()}で編集を行う木から、JungleTreeEditorクラスを取得する。 \item 次に変更するノードの場所を示す、NodePathクラスを作成する。 -\item 関数editor.addNewChildAt()を用いて、変数pathで指定したノードの子供の0番目に子ノードを追加する。 -\item 返り値の変数EitherがErrorクラスを保持していないか(編集に失敗していないか)を確認する。 +\item 関数{\tt editor.addNewChildAt()}を用いて、変数{\tt path}で指定したノードの子供の0番目に子ノードを追加する。 +\item 返り値の変数{\tt either}がErrorクラスを保持していないか(編集に失敗していないか)を確認する。 \item Errorクラスを保持していた場合Exceptionを投げる。 \item 編集に成功していた場合、編集後のJungleTreeEditorクラスを取得する。 \item 取得したJungleTreeEditorクラスを用いて木の変更をコミットする。
--- a/maTrix.tex Tue Nov 29 19:52:37 2016 +0900 +++ b/maTrix.tex Tue Nov 29 22:15:00 2016 +0900 @@ -20,11 +20,11 @@ \end{figure} 図\ref{fig:PersonTree}の人物Treeには、maTrixで使用される人物のデータが記述されている。 -属性名 element 属性値 Personsのデータを持つNode1は、人物Treeのルートノードである。このノードの下に各人物のデータが格納されている(図\ref{fig:PersonTree}ではNode2、Node3が該当する)。 -Node2、Node3が持つ、属性名 element、属性値 Personの値は、Node2、Node3が人物のデータを持っていることを表す。 -またNode2が持つ、属性名 Person-id、属性値 p:1 はこのノードに記述された人物のmaTrix上でのIDを表す。 +属性名 {\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を表す。 他の役職、役割、権限といった木構造は、このIDを用いて参照を行うことで組織構造を構築する。 -Node2、Node3は子ノードに人物の名前、参照する他の木構造のId等のデータを持つが、今回は省略している。 +{\tt Node2}、{\tt Node3}は子ノードに人物の名前、参照する他の木構造のId等のデータを持つが、今回は省略している。 また、maTrixは自身のデータをXML形式で書き出すことが可能である。書き出したデータをJungleに格納するために汎用XMLReaderの実装も行った。 @@ -54,16 +54,16 @@ \subsection{検索APIの実装} Indexを実装したことにより、Idを用いた組織構造の表現は可能になった。 -しかし、組織構造に対する問い合わせを行うための検索APIが実装されていなかったため、属性名 key 属性値 valueの組で検索を行うAPIの実装を、木の走査を行うTraverserクラス内に、lambda式を用いて行った。 +しかし、組織構造に対する問い合わせを行うための検索APIが実装されていなかったため、属性名 {\tt key} 属性値 {\tt value}の組で検索を行うAPIの実装を、木の走査を行うTraverserクラス内に、lambda式を用いて行った。 以下に検索を行う関数findの定義を記述する。 \begin{lstlisting}[frame=lrbt,label=query,numbers=left] public Iterator<TreeNode> find(Query query, String key, String searchValue); \end{lstlisting} -find関数は引数に、Query query、String key、String valueの3つの引数を取り、条件に一致したノードのIteratorインタフェースを返す。 -第1引数には、探索の条件を記述する関数boolean comdition(TreeNode)を定義したInterface Queryを。 -第2、第3引数の、String key、String valueはIndexを用いた絞込みに使用する。find関数の使用例を以下に記す +関数{\tt find}は引数に、{\tt Query query}、{\tt String key}、{\tt String value}の3つの引数を取り、条件に一致したノードの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 @@ -84,15 +84,15 @@ \begin{enumerate} \item 木の走査を行うTraverserクラスを取得する。 -\item Indexからfindの第2、第3引数である、属性名 element、属性値 Personの組のデータを持つNodeを取得する。 +\item Indexから{\tt find}の第2、第3引数である、属性名 {\tt element}、属性値 {\tt Person}の組のデータを持つノードを取得する。 -\item (2)で取得したノードを第1引数のQueryに渡す。 +\item 取得したノードを第1引数のQueryに渡す。 -\item 引数のノードから関数getAttributes().getString("Personid")で属性名 Personidとペアになっている属性値を取得する。 +\item 引数のノードから関数{\tt getAttributes().getString("Personid")}で属性名 {\tt Personid}とペアになっている属性値を取得する。 -\item 属性値がnullだった場合、このNodeには属性名がPersonidの組のデータは存在しないので、falseを返し次のNodeの評価を行う。 +\item 属性値が{\tt null}だった場合、このノードには属性名が{\tt Personid}の組のデータは存在しないので、{\tt false}を返し次のノードの評価を行う。 -\item 属性値がnullでなかった場合、p:2と一致するかどうかを調べ結果を返す。 +\item 属性値が{\tt null}でなかった場合、{\tt p:2}と一致するかどうかを調べ結果を返す。 \end{enumerate}
--- a/renderingEngine.tex Tue Nov 29 19:52:37 2016 +0900 +++ b/renderingEngine.tex Tue Nov 29 22:15:00 2016 +0900 @@ -16,19 +16,18 @@ \end{figure} -RootNodeはContentのtitle、日時、Renderingする時に参照するLayout名を持つ。 +RootNodeはContentの{\tt title}、日時、レンダリングする時に参照するLayout名を持つ。 そして子ノードがContentsの本文等のデータを持つ。 -表\ref{NodeAttribute}にNodeが保持しているContentsの一覧を記述する。 +表\ref{NodeAttribute}にノードが保持しているContentsの一覧を記述する。 \begin{table}[htb] \begin{center} \caption{ノードが保持しているContents一覧} - \begin{tabular}{|c|c|} \hline + \begin{tabular}{|p{8em}|p{12em}|} \hline 属性名 & 属性値 \\ \hline title & 日記のタイトル \\ \hline date(rootNode) & 日記の日時 \\ \hline - type & そのノードが保持しているContextType \\ - & text(日記本文) or image(画像データ) \\ \hline + type & そのノードが保持しているContextType。 text(日記本文) or image(画像データ) \\ \hline date(image) & 画像の保存日時 \\ \hline fileName & 画像の名前 \\ \hline \end{tabular} @@ -40,7 +39,7 @@ htmlの出力形式を定義するLayoutは、複数のComponentからなる。 表\ref{LayoutTreeTable}に、LayoutTreeの主要要素を記す。 Layout Treeには図\ref{layoutTree}のようにデータを格納した。 -また、LayoutTreeはノード同士がNodeNameを用いて参照を行う。 +また、LayoutTreeはノード同士が{\tt NodeName}を用いて参照を行う。 \begin{figure}[hH] @@ -55,37 +54,29 @@ \begin{table}[htbH] \begin{center} \caption{LayoutTreeの主要な要素} -\begin{tabular}{|l|l|} \hline +\begin{tabular}{|p{8em}|p{12em}|} \hline 属性名 & 属性値 \\ \hline -NodeName &ノードの名前。 \\ - &ノード同士の参照時に用いられる。\\ \hline +NodeName &ノードの名前。ノード同士の参照時に用いられる。\\ \hline displayComponent &参照するノードの名前。 \\ -Name &この属性名で取得できる値を持つ \\ - &NodeNameを持つノードを参照する。\\ \hline -use &このノードが、どのContentsに \\ - &対してのLayoutを持つかを。 \\ - &記述するタグ。表\ref{tag}に\\ - &タグとContentsの対応を記述する。\\ \hline -その他 &css等と同じ様な記述を行う。 \\ - &例 属性名 font \\ - & 属性値 fontSize \\ - &など \\ \hline +Name &この属性名で取得できる値を持つNodeNameを持つノードを参照する。\\ \hline +use &このノードが、どのContentsに対してのLayoutを持つかを記述するタグ。表\ref{tag}にタグとContentsの対応を記述する。\\ \hline +その他 &css等と同じ様な記述を行う。 例 属性名 {\tt font} 属性値 {\tt fontSize}など \\ \hline \end{tabular} \label{LayoutTreeTable} \end{center} \end{table} -Layout Treeは、ルートノードに属性名 NodeName 属性値 displayinformation の値を持つ(図\ref{layoutTree}ではNode1が該当する)。 -ルートノードは、子ノードに複数のComponentを保持する(図\ref{layoutTree}ではNode2、Node3がそれに該当する)。 -Node2は、"use" = "image"のペアでタグを保持しているため、Contents Treeの日記の画像表示に対応する記述が行われている。 -Node3は、"use" = "text"のペアでタグを保持しているため、Contents Treeの日記の本文に対応する記述が行われている。 +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の日記の本文に対応する記述が行われている。 表\ref{tag}にタグとContentsの対応を記述する。 \begin{table}[htb] \begin{center} \caption{tagとcontentsの対応} -\begin{tabular}{|c|c|} \hline +\begin{tabular}{|p{8em}|p{12em}|} \hline tag & content \\ \hline image & 画像の表示 \\ \hline cals & table \\ \hline @@ -99,7 +90,7 @@ -layoutが複数のComponentを参照する際は図\ref{multiComponent}のような木構造を構築する(この木はLayoutTreeの一部であり、本来は参照先のノード等が存在している)。 +Layoutが複数のComponentを参照する際は図\ref{multiComponent}のような木構造を構築する(この木はLayoutTreeの一部であり、本来は参照先のノード等が存在している)。 \begin{figure}[h] \begin{center} \includegraphics[height = 8cm , bb=0 0 913 1105]{images/multiComponent.pdf} @@ -108,29 +99,29 @@ \end{center} \end{figure} -図\ref{multiComponent}の例では、diaryMulti@componentはdiaryText@componentとdiaryImage@componentを参照している。 +図\ref{multiComponent}の例では、{\tt diaryMulti@component}は{\tt diaryText@component}と{\tt diaryImage@component}を参照している。 以下に図\ref{contentTree}のContentsTree、図\ref{multiComponent}のLayoutTreeの２つを使用した、レンダリングの流れを記述する。 \begin{enumerate} -\item ContentsTreeのルートノードは、属性名 component 属性値 Multi@Componentの組を持つ。よって今回はLayoutTreeの、NodeNameがMulti@Componentのノードに記述されたルールに則ってレンダリング。 +\item ContentsTreeのルートノードは、属性名 {\tt component} 属性値 {\tt Multi@Component}の組を持つ。よって今回はLayoutTreeの、NodeNameが{\tt Multi@Component}のノードに記述されたルールに則ってレンダリング。 -\item ContentTreeは、属性名 component 属性値 Multi@Componentの組を持つノード、つまりNode2を参照する。 +\item ContentTreeは、属性名 {\tt component} 属性値 {\tt Multi@Component}の組を持つノード、つまり{\tt Node2}を参照する。 -\item Node2はこれ以上データを持たないので、子ノードであるNode3、Node4に記述されているデータの参照を行う。 +\item {\tt Node2}はこれ以上データを持たないので、子ノードである{\tt Node3、Node4}に記述されているデータの参照を行う。 -\item Node3は属性名 displayComponentName 属性名 dialyImage@Componentの組を持つため、NodeNameがdialyImage@Componentのノードを参照する。 +\item {\tt Node3}は属性名 {\tt displayComponentName} 属性名 {\tt dialyImage@Component}の組を持つため、NodeNameが{\tt dialyImage@Component}のノードを参照する。 \item レンダリングエンジンは、参照先のノードに記述されたルールに則ってHtmlを生成する。 -\item Node3は、これ以上データを持たないため、次はNode4を参照する。 +\item {\tt Node3}は、これ以上データを持たないため、次は{\tt Node4}を参照する。 -\item Node4は属性名 displayComponentName 属性名 dialyText@Componentの組を持つため、NodeNameがdialyText@Componentのノードを参照する。 +\item {\tt Node4}は属性名 {\tt displayComponentName} 属性名 {\tt dialyText@Component}の組を持つため、NodeNameが{\tt dialyText@Component}のノードを参照する。 \item レンダリングエンジンは、参照先のノードに記述されているルールに則ってhtmlを生成する。 \end{enumerate} -(4)、(7)で参照しているノードに関しては、図\ref{layoutTree}のNode2、Node3の様な記述が行われている。 +(4)、(7)で参照しているノードに関しては、図\ref{layoutTree}の{\tt Node2、Node3}の様な記述が行われている。 \subsection{Layout Treeのデータ設計} Jungleは汎用の木構造を持つので、データベースを特に設計しなくても、あるがままの形で格納することが可能である。 @@ -155,21 +146,21 @@ \end{figure} -図\ref{goodLayoutTree}のTreeは、１つのNodeにRenderingに必要な値が全て格納されている。 -そのため、Renderingを行う際、複数のNodeをまたぐ必要が無く、簡潔にコードを書くことができる。 +図\ref{goodLayoutTree}のTreeは、１つのノードにレンダリングに必要な値が全て格納されている。 +そのため、レンダリングを行う際、複数のノードをまたぐ必要が無く、簡潔にコードを書くことができる。 -一方、図\ref{badLayoutTree}のTreeはRenderingする際に必要な値が複数Nodeに分散されて保存されている。 -そのため、全てのNodeを参照し、値を集める処理を行う必要があり、コードの可読性が下がり余計な処理も増えてしまった。 +一方、図\ref{badLayoutTree}の木はレンダリングする際に必要な値が複数ノードに分散されて保存されている。 +そのため、全てのノードを参照し、値を集める処理を行う必要があり、コードの可読性が下がり余計な処理も増えてしまった。 \subsection{性能評価} 本節では、図\ref{goodLayoutTree}の木と図\ref{badLayoutTree}を使った2つのRenderinEngineの性能測定を行い、木の構造が実行速度にどれだけ影響するかを確かめる。 -測定は100000回のRenderingRequestを処理するまでの時間の比較で行う。 +測定は100000回のレンダリングリクエストを処理するまでの時間の比較で行う。 測定結果を表\ref{BenchMark}に記す。 -これより、設計を行った木の方が高速にRenderingを行えている。 +これより、設計を行った木の方が高速にレンダリングを行えている。 \begin{table}[htb] \begin{center}