定性的評価

たものと推測される．一方データの取得や加工処理など，明らかにデータ量との比例関係 が予想される項目については測定結果上でも比例関係が認められる．後処理は，データの サイズに関係なくほぼ一定の時間を要している．また，残り2項目(文字列解析，GUI生 成)が全体の処理時間の中で占める割合はきわめて小さい．したがって今回の測定に関す る限り，システムのパフォーマンス向上のためにはエージェントの移動ならびに後処理 の所要時間を短縮することが必要と読み取れる．

また2点目の評価項目においては，本研究においてエージェントを使用することのメ リットを明確に示すことができたと考えている．エージェントを使用しない場合の所要 時間はデータ量に対してほぼ正比例的に増大してゆくが，使用した場合の増加率は非常に 小さい．エージェントを使用すればサーバ側であらかじめ加工処理や圧縮を行うことに よって，データ量を削減してからネットワーク上を移動することができ，通信時間の短 縮やネットワークに対する負荷の軽減が実現される．一方データサイズが小さい場合は，

エージェントを使用しない方が所要時間は短くなるが，サーバ側の豊富な計算機資源を利 用可能，あるいは新たな処理形式にも適応的に対応可能等のエージェントによる利点との トレードオフとなる．

したがって新たなデータ形式や変換方式が出現した場合でも，Process moduleを作成し てデータソース側に追加するだけで対応できる．

1.1.39. 処理機能の柔軟性

1.1.28項に示すように，エージェントは任意の個数のモジュールを動的に組み合わせ

て使用できるので，複雑な処理も柔軟に実現可能である．さらに，図10に示す通りモジ ュールに対するインターフェースは非常に汎用性を持った実装(任意のJavaオブジェクト を使用可能)となっており，DeleGateや情報表現形式自動変換機構におけるフィルタプ ログラムのような「標準入力から入力されたデータを標準出力に出力する」という形式 に束縛されない．

1.1.40. サーバのクロスプラットフォーム性

プログラムの再利用性や保守性を高めるためには，クロスプラットフォーム性を持つ ことが求められる．本研究ではJava言語の使用によりこれを実現した．

1.1.41. クライアントのクロスプラットフォーム性

本研究のようなエージェントを用いたシステムではエージェントが計算機間を移動す るため，特にクロスプラットフォーム性が要求される (5.1節参照)．また，様々な機種が 出現している携帯情報端末においては，クロスプラットフォーム性の実現が強く求めら れる．

1.1.42. クライアント設計の自由度

本システムにおいてクライアント側ユーザインターフェースに既存のソフトウェアを 使うことは想定されていない．このことは既存のソフトウェア資産を継承・活用できな いということを意味する．しかし，エージェントフレームワークによるメリットを最大 限に享受するためにはユーザインターフェースも含めたシステムの再設計が必要である と判断した．またこのことによって，特定の既存ソフトウェアに拘束されることのない，

自由度の高い設計が可能となった．

以上の点を表にまとめたのが表6である．

表6: 関連研究に対する性能評価(再掲)と本研究による解決

↓比較項目 比較対象システム→ M P D J I

プロトコルに対する汎用性 × × ○ × ○

プロトコルの動的追加 × × × × ○

処理機能に関する拡張性 × × ○ ○ ○

処理機能の動的追加 × × × ○ ○

処理機能の柔軟性 × × × × ○

サーバのクロスプラットフォーム性 ○ × × × ○ クライアントのクロスプラットフォーム性(－…任

意)

× × － － ○

クライアント設計の自由度 ○ ○ × × ○

(注 M=KMSF-MCAP，P=ProxiWeb，D=DeleGate，J=情報表現形式自動変換機構，I=

本研究)

7. おわりに

本章では，本研究によって得られた結論と，今後の課題について述べる．