5 設計

1 システムの概要

上記のアプローチに基づき，テスティング支援システムの設計を行った．概要を図5.1に示す．

**Figure 5.1:** 本システムの概要図
$\resizebox{15cm}{100mm}{\includegraphics{MySystemDesign.eps}}$

本システムの動作シナリオを以下に示す．なお，プロバイダが提供するWeb サービスの実体をポートタイプと呼称する．ポートタイプの厳密な定義は，WSDL のportType要素の定義に準じる．

1 テスト対象となるポートタイプの解析

まず，リクエスタが利用するポートタイプの構造を解析し，コードのメタ情報を取得する．この情報は，変換対象となるコードと変換ルールを記述するために用いられる．

以下にシーケンスを示す．

リクエスタは，対象となるポートタイプのプログラムコードに関する情報をテスト用ゲートウェイに問い合わせる．メッセージングプロトコルにはSOAPを用いる．
テスト用ゲートウェイは，プロバイダの実行環境上で動作しているコントローラにリクエスタの要求を転送する．
コントローラは，指定されたポートタイプのプログラムコードを探し出し，内容を解析する．このプログラムコードは，既に実行環境上にロード済みのものを使用する．解析の結果得られる情報は，当該Webサービスの開発に用いられたプログラミング言語および処理系の仕様に依存する．
コントローラは，ポートタイプの解析結果をテスト用ゲートウェイに返送する．
テスト用ゲートウェイは，リクエスタに解析結果をSOAPメッセージとして返送する．

2 テストツール一式の作成，送信，およびセットアップ

リクエスタは，前節で取得したメタ情報を用いてプロバイダの内部情報を利用したテスト用コードを作成し，プロバイダ内部へと送信してフックする．本節の処理が完了すると，テストの準備が整ったことになる．

以下にシーケンスを示す．

解析したポートタイプ情報を使用して，ポートタイプにフックするプログラム断片を作成する．
プログラム断片およびそれをポートタイプにフックするバインディングルール，プロバイダ実行環境を制御または監視するツール，それらの実行に必要なライブラリを，テストツール一式としてまとめる．
テストツール一式をシリアライズし，SOAPエンコードする．
テストツール一式を，テスト用ゲートウェイにSOAPメッセージとして送信する．
テスト用ゲートウェイは，SOAPメッセージをデコードして，コントローラに転送する．
コントローラは，受信したテストツールをデシリアライズし，適切にセットアップ(ポートタイプへのフック，ツールの起動，リクエスタとの通信コネクションの準備など)する．この段階では，テストツール一式はまだ無効である．

3 テスト開始から終了まで

リクエスタによって変換されたコードを有効にして，テストを実行する．

以下にシーケンスを示す．

リクエスタは，テスト用ゲートウェイにテストツール一式の有効化を要求する．
テスト用ゲートウェイは，リクエスタの要求をコントローラに転送する．
コントローラは，テストツール一式を有効化し，ポートタイプの処理に介入する．また，リクエスタとの通信コネクションをテスト用ゲートウェイを通して確立する．
リクエスタは通常のテストケースを実行する．テストツール一式が収集した情報は，テスト用ゲートウェイからSOAPメッセージとして取得する．
テストを一時的に中止する場合は，1～3と同様の手続きを踏んでテストツール一式を無効化する．
テスト終了後，リクエスタは1～3と同様の手続きを踏んでテストツール一式の除去を要求する．

2 構成要素となる技術

本システムの実現にあたっては，シリアライズされたテストコードの送信および適切なセットアップと，ロード済みのポートタイプへのフックが重要な技術的課題となる．この点を解決すべく，本システムでは動的コード変換技術を適用する．

以下，本研究におけるコード変換技術の位置付けを示し，技術的概要と既存技術について述べる．

1 本研究との関わり

本システムにおけるコード変換技術の位置付けと要件について，以下に述べる．

本システムは，ロード済みのポートタイプを直接変換する．したがって，プロバイダの実行環境が実行時コード変換技術をサポートしていることが必須要件となる．

一方，リクエスタサイドでは，テスト用コードの記述容易性が重要となる．利便性の観点から見て，テスト用コードは既存のプログラミング言語を用いて，テストケースの一部としてシームレスに記述できることが望ましい．低級な記法に限定することはテストコードの難読化に繋がる．また，独自記法では，開発者に学習コストを負担させることになる．

しかし，記述性の自由度の観点から見ると，高級な記法のみに限定することは自由度を狭める要因となる．記述能力の限界はテスト用コードの処理系に強く依存するので，コード変換に既存のフレームワークを用いる場合は，その記述能力の限界を見定めた上で適用する必要がある．この点から，高級な記法に特化しているツールを本システムにそのまま適用することは得策とは言えない．開発者の利便性を損ねないという条件を満たした上で，より低級な記法もサポートできるフレームワークを選択するか，または両者の併用を検討すべきである．

上記の観点を踏まえ，コード変換技術について以下説明する．

2 コード変換技術の概要

コード変換技術は，大別して静的な変換と動的な変換に分類できる．

静的コード変換は，コンパイル済みのコードに対し，実行環境にロードされていない状態において変換処理を実行する．一方，動的コード変換は，コードのロード時か，または既にロード済みの状態において変換処理を実行する．

なお，本研究においてコード変換技術と呼称する対象は，変換ルールをプログラマブルに記述可能な手法に限定する．

変換ルールの記述形式は，対象をバイナリレベルで直接操作するものからソースコードレベルの高級言語を用いた指定が行えるものまで様々な種類がある．一般に，前者に近いほど緻密な指定が可能であるが，記述が複雑かつ難解になりやすい．一方，後者は高級言語による記述が可能なので論理的な変換ルールを組みやすいが，コードの振る舞いを完全に制御することは不可能もしくは困難である．

コード変換技術の実現可能性は，その性質上処理系の仕様に極めて依存する．特に動的変換を実現する場合は，データ型やメソッドシグニチャなどのメタ情報を動的に取得する機能を，実行環境がサポートしていなければならない．

3 既存の動的コード変換技術

近年，コード変換技術を用いた新しいプログラミングパラダイムとして，アスペクト指向プログラミング (Aspect Oriented Programming，以下AOP と呼称)[13]が注目されている．

AOPでは，プログラム全体に散在する共通の処理概念を「横断的関心事」とし，プログラムモジュールの再利用性を損ねるものと見なす．そこで，横断的関心事は「アスペクト」と呼称される局所化されたモジュールとして抽出し，既存のプログラムコードに挿入するという手法を採る．AOPは，専らオブジェクト指向開発において，オブジェクト指向方法論ではモジュール化できない処理概念を再利用可能にするものとして，補完的に導入される．

アスペクトはAOP処理系によって対象となるプログラムへ静的または動的に挿入される．挿入するコードポイントは設定ファイルなどの外部リソースに高級な記法で指定する．

動的なAOPは，再利用性の促進効果に加えて，元のコードに静的な影響をまったく及ぼすことなく，容易に，かつ大域的にコードを追加・除去できるという利点を持つ．例えば，デバッグ時にのみ必要なロギング処理をアスペクトとして実装しておけば，実運用に移行した際にプログラム全体をソースコードから再コンパイルすることなく，設定ファイルや起動パラメタの調整のみで除去できる．

既に多くのAOP実装が開発されており，かつ広く普及しているが，いずれもアスペクトの挿入を静的もしくはロード時に実行する手法を採っており，オンメモリのコードに対する変換はサポートしていないか，もしくは機能的に不完全な実装に留まっている．この制限は，実行環境の機能不足に起因する．具体的な詳細は次節で述べる．

4 実行時コード変換可能な処理系

現在，比較的コード変換を容易に実現可能で，かつ最も多く実装が開発されているプログラミング環境はJava[14]である． Javaはインタプリタ型の仮想マシンを実行環境としており，コンパイル済みのコードに対して比較的容易に変更を加えられる．また，デバッグモードや Hotswapなどの実行時コード変換を可能とする機能が仮想マシン仕様に含まれており[15]，動的AOPツールなどロード時または実行時にコード変換を行う実装にとって都合が良いという利点がある．しかし，メソッドシグニチャの動的な追加や変更は不可能であるといった制限もあり，完全な実行時コード変換を実現するには十分でない．将来的にこのような制限は撤廃される予定であるが，現状では各コード変換ツールがそれぞれ独自の手法を用いて制限を吸収している事例が殆どである．

MITSUBAYASHI Shin 2007-03-14