@@-学位(修士)の申請に対し,学位論文の審査及び最終試験を終了したので,下記のとおり報告します。対して2種類の信頼性向上手法を提案していた。-一つはモデル検査的手法であり、総当たりで赤黒木の仕様を検証するメタ計算ライブラリを実装、評価していた。上に定義して言語の形式的な定義を得ることで、CbCで記述されたプログラムの証明を可能にしていた。--予備審査において、証明手法に関する解説が不足しており、証明とプログラムの関係が不透明であることを指摘した。-最終試験時には修士論文上に指摘した部分の解説が追加されていた。--よってこの論文を修士の論文として適切であると認める。その一つがNAT越えの機能である。NAT越えは分散アプリケーション構築における課題の1つでもあるが、プログラマにとってその実装は容易ではない。ManagerにNATを越えたノード間通信機能をつけることにより、ネットワークを気にせずに通信が行えるようにしたい。\ref{fig:nat}はTopologyManagerを用いてNAT越えをするための設計である。\ref{fig:nat}はTopologyManagerを用いてNAT越え(UDPホールパンチング)をするための設計である。DGはAliceと同様にDataGearManager(以下DGM)が管理する。DGMはLocalとRemoteがあり、全てのDGMはCodeGearManager(以下CGM)で管理される。GearsOSではContextという全てのCG/DGを一括管理するプロセスがあり、AliceのCGMもこのContextに相当する。-全てのCGMはThreadPoolと他のCGM全てのリストを共有しているため、全てのCG/DGにアクセス可能である(図\ref{fig:christieClass})。+全てのCGMはThreadPoolと他のCGM全てのリストを共有している(図\ref{fig:christieClass})。+ThreadPoolとは、CPUに合わせた並列度でキューに入ったスレッドを順次実行していく実行機構である。+ThreadPoolが増えるとCPUのコア数に合わない量のスレッドを管理することになり並列性が下がるため、このように共有している。+また、CGMのリストを共有することでメタレベルで全てのCG/DGにアクセス可能となっている。詳しいCodeGearの記述方法については、4.4章で説明する。\section{APIの改善}-ここではAliceのAPIの問題を踏まえて設計したChristieのAPIについて、インプット、アウトプット、データの取り出しに分けて説明する。+ここではAliceのAPIの問題を踏まえて設計したChristieのAPIについて、インプット、アウトプット、型整合の問題に分けて説明する。InputAPIにはAliceと同じくTakeとPeekを用意した。先頭に@をつけることで記述でき、オリジナルのアノテーションを定義することもできる。AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、-ChristieではInputのためのDGを作り、その上にアノテーションでKeyを指定する(ソースコード\ref{src:take})。+ChristieではInputとなる型の変数を直接宣言し、変数名としてkeyを記述する。+そして、その宣言の上にアノテーションでTakeまたはPeekを指定する(ソースコード\ref{src:takeex})。アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。-これにはJavaのreflectionAPIを利用している。--Christieのこのインプットアノテーションはフィールドに対してしか記述できないため、InputDGの生成とTake/Peekの指定とkeyの指定を必ず一箇所で書くことが明確に決まっている。-そのためAliceのように外のCSからのkeyへの干渉をされることがない。-また、アノテーションの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。-このように、アノテーションを用いたことで、Aliceの記述の分離問題が解決された。+これにはJavaのreflectionAPIを利用しており、アノテーションと同時に変数名も取得できるため、変数名によるkey指定が実現した。-ソースコード\ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。内に指定した型でデータの型を限定できる。-このように記述することで、Christieでは他の部分を辿らなくてもCGを見るだけでインプットされるデータの型が分かるように可読性を向上させた。-また、取得してきたDGが指定と違う型であった場合はエラーとなるため、型の整合性を保ちながら信頼性の高いプログラミングが可能となった。+Christieのこのインプットアノテーションはフィールドに対してしか記述できないため、keyの指定とTake/Peekの指定を必ず一箇所で書くことが明確に決まっている。+そのためAliceのように外のCSからのkeyへの干渉をされることがない。+このように、アノテーションを用いたことで、Aliceの記述の分離問題が解決された。+また、keyを変数名にしたことで、動的なkeyの指定や、keyと変数名の不一致による可読性の低下を防ぐことができた。-また、Aliceではkeyと変数名の不一致から可読性が低くなっていた。-しかしChristieではkeyと変数名が一致しないとエラーとなるため、自然と読みやすいコードが書けるようになっている。-この部分に関しては、JavaのメタプログラミングAPIであるJavassist\cite{javassist}を用いてアノテーションから変数の自動生成も試みたが、Javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。-+リモートノードに対してTake/Peekする際は、TakeFrom/PeekFromのアノテーションを用いる(ソースコード\ref{src:remotetake})。-リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのアノテーションを用いる(ソースコード\ref{src:remotetake})。-そのため待ち合わせ先がLocalかRemoteかはアノテーションの違いからひと目でわかるようになった。ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける(ソースコード\ref{src:compresslocal})。-LocalからのTAKEではDGM名の指定がないが、それはLocalでの圧縮は基本想定していないためである。-しかし、Localでの圧縮をしようと思えばRemoteTakeを用いて間接的にすることは可能である。OutputAPIにはput/flipを用意した。-put/flipのメソッドはDGMに用意されている。-cal.java-CodeGear.classにはDGMを取得するメソッドがあり、それを用いて書き込みたいDGMを指定して直接putする。-そのためLocal/Remoteの切り替えは指定するDGMの切り替えによって行う。-ソースコード\ref{src:put}、\ref{src:remoteput}はLocalとRemoteにputする記述の例である。+基本的なシンタックスはAliceと同様だが、Christieではput/flipのメソッドはCodeGear.classに用意されている。+そのためCodeGear.classを継承するCGで直接putメソッドを呼ぶことができる(ソースコード\ref{src:remoteput})。-flipも同様にDGMに直接DGを渡す(ソースコード\ref{src:flip})。caption=Remoteへflipする例]{source/christie/Flip.java}--ChristieではDGMに対して直接putするため、AliceのODSにあたる部分はない。+そのため、ChristieにはAliceのODSにあたる部分がない。ODSを経由するより直接DGMに書き込むような記述のほうが直感的であると考えたためである。+圧縮を指定してのputも、Alice同様DGM名の前にcompressedをつける。-\subsection*{型を指定しないデータの取り出し}-AliceのasClassに相当するのがgetDataである。-ソースコード\ref{src:getdata}はgetDataを用いてInputDGからデータを取得する例である。+\subsection*{型の整合性の向上}+ChristieではReceiver型ではなく直接変数を宣言する。+そのため他の場所を辿らなくともCGを見るだけでインプットされるデータの型が分かるようになった。+また、変数を直接宣言するため、そもそもAliceのようにasClassメソッドで型の取り出す必要がない。+ソースコード\ref{src:getdata}はInputDGのデータを扱うである。-Aliceと違う点は、プログラマが型を指定しなくて良い点である。-4.3で示したように、InputDGを生成する際には型を指定する。-この型は内部で保存され、リモートノードと通信する際も保たれる。-このようにgetDataするだけでプログラマが指定しなくとも正しい型で取得できるため、プログラマの負担を減らし信頼性を保証することができる。+InputDGとして宣言した変数の型は、reflectionAPIにより内部で保存され、リモートノードと通信する際も適切な変換が行われる。+このようにプログラマが指定しなくとも正しい型で取得できるため、プログラマの負担を減らし信頼性を保証することができる。StartCGで事前にRemoteDGMを生成しておく。-RemoteTakeアノテーションからRemoteDGMに対するTakeコマンドを生成し実行する。-RemoteTakeのようにリモートからの応答を待つコマンドはRemoteDGMのwaitListに入る。+TakeFromアノテーションからRemoteDGMに対するTakeコマンドを生成し実行する。+TakeFromのようにリモートからの応答を待つコマンドはRemoteDGMのwaitListに入る。MessagePack形式に変換したRemoteCommandを作成し、それをRemoteDGMが参照している別ノードのLocalDGMに送る。それを受け取った側のLocalDGMは、DGがあればREPLYコマンドを生成して送り返す。REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。-\chapter{再設計への考察}-Christieではアノテーションを用いることで分離問題を解決することができた。-このようにアノテーションを用いたAPIはAkkaやHazelcastにはないため、より記述性が高いフレームワークとなったと言える。Computationの実装が容易になった。-これにより細かな分散プログラムの実装が可能になった。-ロケーション透過性の高いAkkaやHazelcastではこのようなプログラミングは困難である。--InputDGの指定において、CGにDGを宣言するというのは、DGをそのままflipできるようにするためであった。-逆に言えばそれ以外でDataGear型でプログラマが利用することは少ない。-そのため、DGを宣言せずにアノテーションから生成し完全にメタレイヤーに移すことで、より分かりやすい記述が可能である。-flipする場合は、keyを指定するだけで行えるようにすべきである。--また、put/flipする際にDGM名を直接指定する書き方も、まだひと目でアウトプットしている部分が分かるようなシンタックスではないため、改善の余地がある。本研究では、まず分散フレームワークに必要な要件を洗い出し、Akka、Hazelcastと比較しながら分散フレームワークAliceが分散性を意識して記述できる特徴をもつことを示した。Computationについてを説明し、AliceでNAT越えを実現するための手法を示した。Managerの複数立ち上げができないこと、分散プログラムのテストがしづらいこと、APIシンタックスの分離により信頼性が損なわれていること、型の整合性がとれていないことなどを示し、再設計の必要性を述べた。Managerを複数立ち上げられるようにした。これによりテストが容易になり、提案したNAT越えの手法に対応できる。アノテーションを用いることでシンタックスの分離問題を解決し、さらに型整合のとれたより信頼性の高い記述が可能になったことを示した。-そして、これら実装したChristieに対しても更に改善すべき点を考察した。+このようにアノテーションを用いたAPIはAkkaやHazelcastにはないため、より記述性が高いフレームワークとなったと言える。CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。+\subsection*{コンパイル時の型検証}+InputDGで待ち合わせた型と実際に取得した型が違った場合、現段階ではランタイムエラーとなる。+しかしアノテーションはProcessorを記述することでコンパイルエラーを出すことができる。+この機能を用いて型の不一致をコンパイル時に発見できるようにすることが望ましい。DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。ソースコード\ref{src:take}、\ref{src:remotetake}がChristie独自のアノテーションの定義である。@Targetや@Retentionはアノテーション定義のためのアノテーション、メタアノテーションである。@Targetには、フィールドやメソッド、コンストラクタなど、このアノテーションの付加対象となる構文要素が何かを記述する。定義したアノテーションの仕様例がソースコード\ref{src:takeAno}、\ref{src:remotetakeAno}である。-アノテーションを使う際、()内に記述する値がソースコード\ref{src:take}のvalueやソースコード\ref{src:remotetake}のdsmNameといったキーに保存される。-通常キーに対して値を入れる場合は、ソースコード\ref{src:remotetakeAno}のようにkey=の形で記述しなければならないが、Takeのようにキーが1つの場合、キー名をvalueにすることでその記述を省略することができる。+アノテーションを使う際に()内に記述する内容が、ソースコード\ref{src:remotetake}のようにvalueというキーに値が保存される。setupメソッド内では生成されたフィールドに対してアノテーションを含めた情報を処理している。これにはJavaのreflectionAPIが使用されている。-フィールドから取得したDGとアノテーションから取得したkeyからインプットコマンド(TAKE/PEEK)を生成し、DGMへ送って実行する。+フィールドから取得したkey名とアノテーションから取得したコマンドタイプ(Take/Peek)からインプットコマンドを生成し、DGMへ送って実行する。数々の貴重な御助言と技術的指導を戴いた伊波立樹さん、他フレームワークの調査に協力してくださった清水隆博さん、赤堀貴一さん、浜瀬裕暉さん、大城由也さん、並びに信頼研究室の皆様に感謝いたします。TreeVNCがなければ本研究はありませんでした。これら先行研究の設計や実装に関わった全ての先輩方に感謝いたします。-また、本フレームワークの名前の由来となったクリスティー式戦車の生みの親、ジョン・W・クリスティーに敬意を評します。+また本フレームワークの名前は、BT42などの戦車に用いられるクリスティー式サスペンションが+由来となっています。+CodeGearなどのギアで動くイメージ、また、履帯走行と車輪走行を切り替えながら高速に走れるフレキシブルな構造から、そのようなフレームワークになればと名付けました。+クリスティー式戦車の生みの親、ジョン・W・クリスティーに敬意を評します。最後に、日々の研究生活を支えてくださった新里幸恵さん、大嶺志歩さん、阿波連知恵さん、米須智子さん、菱田正和さん、情報工学科の方々、そして家族に心より感謝いたします。\'81\'45\expnd0\expndtw0\kerning0+CGM\'82\'f0CG\'8a\'d4\'82\'c5\'88\'f8\'90\'94\'82\'c5\'8e\'9d\'82\'bf\'95\'e0\'82\'ad\'82\'b1\'82\'c6\'82\'c5\'81\'41CGM\'82\'a9\'82\'。