2004 年度 卒業論文
ユビキタスコンピューティング環境における 現場指向の開発支援ツール
提出日 : 2005 年 2 月 2 日 指導 : 中島 達夫 教授
早稲田大学理工学部情報学科 学籍番号 : 1G01P032-8
神戸 猛
概 要
ユビキタス社会が叫ばれる昨今，ユーザが置かれた環境や状況を把握するた めに日常生活品によるコンテクストの抽出が必要不可欠である．今日，センサ デバイスを埋め込んだ日常生活品は徐々に増加しているが，それを統合するアプ リケーションが少ないのが現状であるといえる．これは，知的な日常生活品を統 合したアプリケーションの開発が容易ではないことから来ているのではないだろ うか．
本研究では，そういった知的な日常生活品の統合における課題を抽出し，そ の課題を解決するためのアプリケーション開発の将来像の１つとして，「現場指向 の開発支援ツール」を提案する．実際に対象となる知的な日常生活品を目の当た りにしながらアプリケーションを開発することで，アプリケーション開発者の開 発効率を向上させることができると考えたからである．本論文では，この「現場 指向の開発支援ツール」の詳しい概要から実装，評価に至るまでを述べる．
Abstract
. which can say that there is little application which unifies it as for the present condition although the everyday-life article which embedded the sensor device is increasing gradually . today when extraction of the context by the everyday-life article is indispensable in order to grasp the environment and the situation that the user was placed these days when YUBIKITASU society is cried for – probably, this is coming from development of the application which unified the intellectual everyday-life article not being not easy As one of the future images of the application development for extracting the subject in integration of such intellectual everyday life articles, and solving the subject in this research By developing application, carrying out the intellectual target everyday life article before one’s eyes in the . fruit case which proposes ”the development support tool of an on-site inclination” . book paper which is because it thought that an application developer’s development efficiency could be raised describes the period until it results [ from the detailed outline of this ”development support tool of an on-site inclination” ] in mounting and evaluation.
目 次
1 序論
1.1 背景
近年，計算機機能の小型・高性能化および無線通信技術の発達に伴い，我々の周囲 には様々なデバイスが直接的もしくは間接的にネットワークに接続され，日常生活に 自然な形で計算機が組み込まれるようになりつつある．このような環境はユビキタス コンピューティング環境（以下，ユビキタス環境）と呼ばれ，計算機と人との関係に おける新たな段階として，1990年代初頭より研究されてきた．このユビキタス環境に おいては，「コンテクスト」と呼ばれるデータをいかに取得し利用するかということが 非常に重要である．
コンテクストとは元来「状況」や「文脈，前後関係」という意味で使われるが，ユ ビキタス環境においては次のような意味で用いられる．
絶えず変化している実行環境（コンピューティング環境，ユーザ環境，物理環境）に おいて，ユーザとアプリケーションとの間の相互作用に関連すると考えられるエンティ ティ（人，場所，オブジェクトなど）の状況を特徴化するために利用されるあらゆる 情報．
つまり，あるオブジェクトに取り付けられたセンサが取り得る値も一つのコンテクス トであり，人間が「椅子に座る」という動作もコンテクストである．そして、このコ ンテクストの内容や変化を把握することをコンテクストアウェアネスと言う．コンテ クストアウェアネスは，コンテクストを検知かつ取得することのみならず，さらにい くつかの取得したコンテクストを組み合わせ，解釈することによって，より上位のコ ンテクストを把握することも指している．
コンテクストアウェアなシステムを開発する上で重要なことは，ユーザの状況を取 得されたコンテクストからいかに認識するかである．ユーザの状況の多くは単一種別 の情報では表現できないため，複数種類を統合して利用することになる．また，情報 の不確実さを軽減する意味で相補的な情報源を組み合わせることもある．このコンテ クストを「統合する，組み合わせる」というステップにおいて，コンテクストのフォー マットの違いや統合手順の複雑さといった多くの課題があるのではないだろうか．本 論文は，コンテクストアウェアな空間を実現する上で必要となるコンテクストの統合 における課題について議論し，その課題を解決するための手段を提案する．
1.2 研究目的
本研究では，まず背景で述べたようなコンテクストの統合において，どのような障 害や難しさがあるのかを把握すべく，実際に知的な日常生活品（第2章）を複数用い て，ユーザに関するコンテクストを抽出・解析し，ユーザの状況に合ったサービスを
1.3 構成
本論文は，第2章で現在我々の研究の一環として開発されている知的な日常生活品
（Sentient Artifact）を紹介し，実際にそれを統合利用したアプリケーションを開発し，
統合の難しさを検証する．第3章では前章を踏まえ，知的な日常生活品の統合利用を 支援するミドルウェアであるBazaarの導入について述べる．第4章では，本題とな る知的な日常生活品の統合における障害を取り除くためのアプローチとして，「現場指 向の統合開発環境」を提案し，現場指向開発とは何か，開発した統合開発環境（IDE） はどのようなものかなどを述べていく．第5章は前章の「現場指向の統合開発環境」
を，開発スタイルである現場指向開発の部分と，開発ツールとしての自作IDEの部 分に分けて評価・考察を行う．第6章は，現場指向の統合開発環境の将来課題を挙げ，
実現可能性を検討する．第7章では，本論文の結論を述べる．
2 知的な日常生活品： Sentient Artifact
2.1 Sentient Artifactとは
Sentient Artifactとは直訳すると「感覚のある人工物」となるが，我々の研究では
次のように定義している．
日常生活品にセンサを取り付け，コンテクストを知覚し，計算し，通知する機能，お よびアクチュエータを持ったもの．
ここで我々が重要であると考えているのは，日常生活品（以後、モノ）の持っている 本来の機能を損なうべきではないということである．つまり，あくまで知覚機能は付 加価値なのである．
では，Sentient Artifactのアーキテクチャとはどのようなものか．Sentient Artifact には大きく分けて「コンテクスト抽出」と「アクチュエータ」の2つの機能がある．
まずコンテクスト抽出について述べる．一言にSentient Artifactといっても様々な モノの拡張が考えられるため，コンテクスト抽出についても様々なアプローチが存在 するのであるが，基本的な考え方は「モノに取り付けられたセンサから取得できる値 をモノ自身で解析し，状態を返す」というものである．つまり，センサから取得でき る値をそのまま返すわけではないということである．センサの値は種類によっても異 なるが，速いものでは数100Hz程度のサンプリング周波数で取得される．近年，ネッ トワークの高速化・安定化が進んだとはいえ，このようなセンサの生データをネット ワークに放出してしまうのは，相当な付加になると考えられる．しかも，今後Sentient
Artifactのような知的なモノが世の中を埋め尽くした場合，さらなるデータの飽和状
態になりかねない．従って，モノの側でセンサの生データを解析し，ある程度までコ ンテクストを高度なものにする必要がある．
次にアクチュエータについて述べる．アクチュエータとはモノ自身の振る舞いのこ とである．例えば，ライトで言えば「点灯する」「消灯する」という振る舞いがアク チュエータである．各Sentient Artifactのアクチュエータは，モノ自身が取得したコ ンテクストから判断して起動するものや，他のモノのコンテクストによって外部から ネットワークを介して起動されるもの，またはそのどちらも持ち合わせているものが ある．
ここまではSentient Artifactの概念を述べてきた．次節では実際にSentient Artifact の例を挙げていく．
2.2 Sentient Artifactの例
この節では，実際に作成されたSentient Artifactを紹介することで，Sentient Ar- tifactとはどんなものなのか理解を深めていただきたい．Sentient Artifactの作成に
2.2.1 Senteint Phone Cradle
概要 携帯電話ホルダーを拡張したものであり，携帯電話のバイブレーション を感知すると，人形の足をバタバタさせ，ユーザに着信を伝える．また，不在 着信件数を保持する機能があり，足のばたつき具合によって，着信件数を知ら せてくれる．動作は前面をタッチすることによって停止できる．外部からの操 作により，不必要時（睡眠時や外出時など）には動作をさせなくすることもで きる．携帯電話の着信という日常の光景に楽しさを与える目的で作成された．
使用センサ
• ON/OFFスイッチ 携帯電話の有無を検知．
• 加速度センサ 携帯電話のバイブレーションを感知．
• タッチセンサ 動作の停止．
コンテクスト
• 携帯電話の有無．
• 着信の有無．
• タッチセンサに触れたことから得られるその場所における人の存在有無．
アクチュエータ
• 足のバタつき（バタつきレベル調節可）．
• 動作可否．
図1: Sentient Phone Cradle
2.2.2 Sentient Toothbrush
概要 歯ブラシを拡張したものであり，歯ブラシの使用状況が取得できる．規 定以下のブラッシング回数で磨くのを止めてしまうと，警告音が鳴り注意を促 す機能を持っており，しっかりと歯を磨いているか監督することができる．歯 ブラシは他人が使用する可能性が極めて低いため，人物判定にも応用が可能で ある．
使用センサ
• 2軸加速度センサ 歯ブラシの振動検知．
コンテクスト
• 歯ブラシの使用有無を検知．
図2: Sentient Toothbrush
2.2.3 Sentient Umbrella Stand
概要 傘立てを拡張したものであり，傘がセットされているかどうかを判定で きる．
使用センサ
• 光センサ 傘の有無を検知．
コンテクスト
• 傘の有無無．
アクチュエータ
• LED点灯．
図3: Sentient Phone Cradle 2.2.4 その他
上述のSentient Artifact以外にも，椅子の着座状況が取得できるSentient Chair（図
??），鏡の前に人物がいるか否かを取得でき，鏡面を利用して様々なコンテンツを表
示できるAware Mirror（図??），鞄を持った人物が歩いているか否かを取得できる
Sentient Bag（図??），ドアの開閉状況を取得できるSentient Door（図??）など，我々 に大変身近な日常生活品を拡張したものを作成している．
図4: Sentient Chair
図5: Aware Mirror 2.3 Sentient Artifactの統合
ここまでは，Sentiet Artifactがモノ本来の機能をそのままに，付加価値としてコン テクストの抽出やアクチュエータの実行ができるものであることを具体例と共に述べ た．では，Sentient Artifactは単体で我々人間に関するコンテクストを取得できるの であろうか？例えば，前節に紹介したSentient Chairの抽出できるコンテクストは，
誰かに座˙ら˙れ˙て˙ い˙るかどうかであって，○○という人間が座っているかどうかではな˙ い．また，Setient Toothbrushは単体で人物識別ができるが，これも□□の歯ブラシ が使˙わ˙れ˙て˙い˙ることからの応用解釈に過ぎず，万が一間違って他人のものを使用され˙ たら，人物識別のコンテクストは不正確なものとなる．問題なのは，ユビキタス環境 とは本来人間の生活を豊かにするためにコンピュータがサポートすることが目的であ るのにもかかわらず，Setient Artifactが保持できるコンテクストはあくまでそのモノ のコンテクストであって，人間の状態ではないことである．つまり，モノを中心とし た表現になるため，1つのSentient Artifactから取得できる人間に関するコンテクス トは少なく，精度が低いのである．
そこで重要になってくるのがコンテクストの統合であり，すなわちSentient Artifact の統合である．ユビキタス環境構築において，人間の状態を抽出することは最大の難 関であるといえる．
2.4 Setient Artifactの統合例
この節では，Sentient Artifactの統合利用，実際にSentient Artifactを利用したア プリケーションを作成することによって述べていきたい．
2.4.1 アプリケーション例
ユーザの起床中／就寝中のコンテクストを身の回りにあるSentient Artifacatから 取得し，Sentient Phone Cradle（以下，クレードル）を起床中のみ動作を許可する アプリケーションを作成した．今回ユーザの起床中／就寝中のコンテクストを取得す るのに用いたSentient Artifactは，Sentient Alarm Clock（以下，目覚まし時計），
Sentient Toothbrush（以下，歯ブラシ）である．
目覚まし時計は，目覚ましのセット，およびセットされた時間が来るとベルが鳴る，
鳴った後ユーザが気が付けば止める，という3つの状態変化を検知することができる．
目覚ましのセットしたという状態変化は「ユーザの就寝意思」というコンテクストを 取得できる．ベルが鳴るという状態変化は「ユーザの起床意思」を表し，ベルが止め られるという状態変化は「ユーザの起床」というコンテクストが取得できる．
歯ブラシは，前述のとおりユーザの特定が可能（ただし，ユーザの予期せぬ行動に より誤ったコンテクストにもなり得る）であり，歯ブラシが使われているということ は，その歯ブラシのユーザは起きているというコンテクストが取得できる．
ここで開発するプログラムでは，目覚まし時計のセットをユーザの「就寝」，目覚 まし時計のベルが鳴ることとユーザの歯ブラシが使われていることをユーザの「起床」
というコンテクストとして使用した．前者はユーザは「眠ろう」という意思から目覚 ましをセットしているのであるから，実際にはユーザが眠っていなくても，クレード ルは動作して欲しくないと考えられる．同じように，後者の目覚まし時計のベルが鳴 ることは，例えユーザが起床していなくても，ユーザは起きようとしている，もしく は起きなければならないと解釈することができ，クレードルは動作しても問題ないと 考えられる．
2.4.2 アプリケーション開発の流れ
図(T.B.D.)のように，まずメインプログラムでは，Sentient Artifacatの状態変化 をいつでも受け取れるようにサーバのようにポートを開放しておく．一方，目覚まし 時計の側では「セット」「ベルが鳴る」という状態変化が現れた場合にメインプログ ラムに知らせるようにする．同様に歯ブラシも「使用開始」という状態変化が現れた 場合に知らせるようにする．歯ブラシについては，ユーザ判定をする必要があるので，
状態変化と共にユーザ情報も通知するようにする．メインプログラムでは，目覚まし 時計が「セット」と知らせてくると，クレードルに動作OFFに設定するよう通知す る．また，目覚まし時計が「ベルが鳴る」，もしくは歯ブラシが「使用開始」と知ら
せてくると，クレードルに動作ONに設定するよう通知する．クレードルの側ではメ インプログラムからの通知が受け取れるようポートを開放しておく．
2.5 Sentient Artifactの統合の難しさ
アプリケーション開発例のようにSentient Artifactを統合するには数多くの手順を 踏まなければない．特にポートを開くといったネットワーク通信部分の管理は，開発 者の手を煩わすことが多い．また手順だけでなく，各Sentient Artifactのネットワー ク上の位置（IPやポート），取り得る状態，アクチュエータの起動方法といった様々 な情報も知っておかなければならない．開発者はこうした情報をあらかじめ設定ファ イルや仕様書からかき集め，準備してからでなければ統合できない．これはあまりに も非効率であり，Sentient Artifactそのものの普及も妨げてしまう．
そこで必要となってくるのが，各Sentient Artifactの通信インタフェースを決定し，
さらに統合利用をしやすいよう中央集権的にSentient Artifactを管理することである．
本研究では，筆者の所属する研究室で開発されたBazaarというミドルウェアを用い て，統合利用時の煩わしさを取り除くことにした．
3 Bazaar
3.1 Bazaarとは
Bazaarは，筆者の所属する研究室の藤波氏によって開発されたSentient Artifactの 統合利用を支援するミドルウェアである．このミドルウェアでは，以下の機能を提供 することを目的としている．
• 豊富かつ柔軟な意味表現の支援
• 多様なロケーションシステムおよびロケーションモデルの扱い
• モデルの表現手段と利用側の分離
• 環境の動的な変化への対応
• 利用の直感性
基本設計は図??に示すような6つの要素により構成される．すなわち，1) 低いレ ベルのコンテクスト情報源となりうる物理オブジェクト，2) システムへの入出力と なるセンサおよびアクチューエータ，3)任意の空間モデルを提供するBazaar World Model Manager(BWMM)，4)高レベルのコンテクスト情報を抽出するためのフレー ムワーク，5)アプリケーションの動作を表現するアプリケーションロジック，6) API である．
Bazaarのコアとなる考え方は自己記述的な物理オブジェクトの集合によりワールド
モデルを表現するところにある．これにより，空間に存在する各物理オブジェクトは それぞれの属性を独立のボキャブラリにより空間モデル（BWMM）に提供すること になる．
一意な識別子（ID）は個々の物理オブジェクトに割り当てられ，これが仮想空間内 で当該物理オブジェクトを識別することになり，これに関連した自己記述情報を扱う ことが可能となる．このIDは以下のような様々な手段で位置情報と関連付けられた 上でBWMMで管理される．
■ 外部による自動登録 無線タグシステム（RFID）や，Active Batのような超音 波等を用いた外部インフラを用いる方法
■ 物理オブジェクト自身による自動登録 GPSのような測位システムを所有した 物理オブジェクト自身が通知する方法
■ 人手による登録 開発者または利用者が直接登録する方法
このような複数の手段をサポートすることにより，上記のいずれかの方法でIDが
Bazaar内で認識され，BWMMに登録されれば当該物理オブジェクトはBazaar内で
透過的に扱われるようになる．これはコンセプトに挙げた，多様な物理オブジェクト の扱いに対する要求条件への解である．自己記述情報は新規に物理オブジェクトが BWMMに登録される時に物理オブジェクト自身または外部より取得され統合される．
その所在は図??におけるIDResolverと呼ぶコンポーネントが解決する．なお，ID自 身に定義ファイルのURLをエンコードできる場合には，IDResolverによる解決は除 外することができる．
図6: Bazaarの構成
また，Bazaarでは空間モデルを直感的に扱うためのプログラムモデルを提供する．
そこでは開発者に対して，日頃慣れ親しんだ物理空間に存在するオブジェクトや概念 がオブジェクト指向言語におけるクラスとして提供される．以下の節では具体的な空 間モデルの設計，表現方法，管理方法，利用方法について述べる．
Bazaarにおけるワールドモデルは，小規模な屋内空間においてそこに存在するSen-
tient Artifactから得られるコンテクストを用いて当該空間内でユーザにフィードバッ
クされるような用途を前提とする．ここでモデルとして形式化すべき情報は，個々の Sentient Artifactの場所，それらの静的および動的な属性である．
ロケーションモデル
詳細で複雑な統一モデルはかえって共有を阻害すると考えられるために，ロケーショ
そして，様々な手段でBWMMに登録される物理オブジェクトは，この単位領域に関 連付くことになる．部屋やフロア間の隣接や包含関係といったトポロジカルな関係に ついては極力シンプルな構造とするために本ロケーションモデルの範疇外とする．そ してこれらの関係はアプリケーションの一部として定義することになる．上述のよう に単位領域にはシンボリックな名前が付けられ，名前空間は任意にとることができる．
オブジェクトモデル
オブジェクトモデルはSentient Artifactの静的な仕様や動的な実行状態を表してお り，ロケーションモデルと同様に極力シンプルな構造が求められる．最低限共有する 情報としては表に示したようなものが挙げられる．表中でcardinalityは重複度を表す．
製造業者などにより初期設定として設定される静的情報には，ID，オブジェクトタイ プ，アクチュエーション機能などがある．アクチュエーション機能に関しては，全て のオブジェクトに必須なものではなく，外部から機能にアクセスする際のコマンド情 報（コマンド名，引数名および型，返り値名および型）が設定される．
一方，物理オブジェクトが存在する環境により動的に変化する情報には，ロケーショ ン，使用状況，および所有者などが挙げられる．ロケーション属性はロケーションシ ステムにより検出される単位領域が関連付く．なお，一つの物理オブジェクトに対し て複数の単位領域の関連付けを許す．これは，検出領域が重複しているロケーション センサにより同時にIDが検出された場合に，複数箇所で検出されているという事実 をそのまま表し，モデルを利用する側が解釈を加えるべきであると考えられるからで ある．このようなロケーションセンサには，無線タグシステムやActive Badgeシステ ムのように外部が存在するロケーションセンサによりIDを検出システムが該当する．
種別1 種別2 Candinality 例
静的属性 ID 1 ABCDE
オブジェクトタイプ 1 イス
アクチュエーション機能 0以上 コマンド情報地 動的属性 ロケーション 1以上 玄関
使用状況 1以上 着座
使用者 1以上 Taro
所有者 1以上 Hanako
表1: Bazaarワールドモデルにて扱うオブジェクトモデル属性例
また，使用状況は物理オブジェクトがSentient Artifactの場合に取得可能となる情 報を表している．この情報についてもロケーションと同様，同時に複数持ち得ること とする．これは前述のSentient Chairに見られたように，「sitting（着座）」と「45°
（北東）」という着座有無と方角の2種類の分離可能な情報を同時に取得することがあ るからである．
この他にも使用者および所有者といった属性も必要になる．使用者の場合は物理オ ブジェクト自体に個人識別機能がある場合や，外部からカメラなどを用いて特定され る場合にはその旨を示すことで，利用例が例えば所有者情報を用いて近似するといっ た任意の処理を行うことができるようにする．このような判断はアプリケーションご とになされるべきものなので，その結果をオブジェクトモデルに反映することはしな い．最後に所有者の場合は，譲渡したり共有するようになったりする以外は変化の速 度は遅いものであるが，使用者を推定したり携行品を特定するような場合に必要とな る．一つの物理オブジェクトを共有することを考慮してこの場合も同時に複数の値を 持ち得るとする．
なお，Schmidtが指摘するように動的な情報に関しては時間経過とともに情報の価
値が変化するためにタイムスタンプ情報が必要となる．また，取得される情報の正し さ（Activity），精度（Precision），確信度（Confidence）といった品質情報について も可能であれば添付すべきである．これらは，前述のメタコンテクストという情報と いうことができる．
3.2 Bazaarのプログラミングモデル
BWMMにて管理されている空間モデルを開発者が利用するたものプログラミング モデルについて述べる．直感的な操作性を提供するため，物理オブジェクト，アクチュ エータ，コマンド，場所，状態，そして，物理空間といった物理世界に存在し直感的 に捉えられる概念や一般的な抽象概念を明示的に扱うためのクラスおよびAPIを提供 する．これらの概念はそれぞれArtifact（物理オブジェクト），Actuator（アクチェー タ），Command（コマンド），Location（場所），State（状態），World（物理空間）
といった汎用的なクラスとして表現されている．自己記述情報として与えられるその 他の属性情報はArtifactクラスをインスタンス化したオブジェクト中に格納される．
ここで属性情報はいわゆる key-valueペア で管理される．具体的にはJava言語に
おけるHashtable内で格納される．このことは，厳格なオブジェクト指向モデリング
と比べて，敬称による柔軟な拡張とイントロスペクションによる開発ツールによるサ ポートを失うことになる．しかしながら，前述のとおりユビキタスコンピューティン グ環境の多様性という特徴のために完全に分析してモデル化することは非常に困難で ある．したがって，6種類の基本的な要素のみをモデル化し，他の情報についてはテー ブル管理によるアクセスをすることとした．
BWMMに対しては以下のような3種類の基本的な操作を行う．また，図（T.B.D.） にプログラミングモデルの概念図を示す．
■ BWMMより取得 一つまたは複数の属性を用いて関連するオブジェクトを BWMMより取得する．これには，物理オブジェクトからそれが存在している
は物理オブジェクトに着目した検索であり，「イスはどこか？」といった問いに 答えるものである．一方，後者は場所に着目した検索であり，「人口には何があ るか？」といった問いに答えることに相当する．こうして取得した物理オブジェ クトを表すオブジェクトから，上述の他の基本要素オブジェクトを取得するこ とができる．
■ 属性情報 これはBWMMより取得されたオブジェクトからそれが保持する属 性情報を取得ものである．例えば，物理オブジェクトの所有者を取得する操作 が該当する．取得にあたっては，種別のような基本要素をgetTypeといった固 有のメソッドにより取得する場合と，テーブルよりgetAttributeといった汎用 的なメソッドを用いる場合がある．
■ イベントリスナ登録 物理空間における状態変化に応じた処理を記述する場合に 必要となる．すなわち，任意の場所への物理オブジェクトの入退出（図（T.B.D.）： E1），あるいはBWMMにより取得された物理オブジェクトの状態や場所の変
化（図（T.B.D.）：E2）を利用する場合にイベント通知用のリスナオブジェクト
を登録するというものである．例えば，ある物理オブジェクトの移動を利用した い場所に利用側がイベントリスナを登録する．これはGUIウィジェットを利用 した開発において今日の開発者にとってなじみ深いものであり，容易に受け入れ られると考える．なお，イベントリスナにはこれらの3種類の変化に対応して，
Detectionリスナ（DetectionListener），Locationリスナ（LocationListener），
Stateリスナ（StateListener）がある．
また，Artifactオブジェクトから取得できる他のオブジェクトを利用することで，物
理空間の様々な情報を取得したり，働きかけることができるようになる．例えば，場 所をキーとして取得したオブジェクトから最新の使用状態を取得したり，その物理オ ブジェクトが外部から制御可能であればコマンドを発行することでライトの点灯のよ うに環境に対してアクチュエーションをすることができるようになる．
なお最新状態の取得にあたっては，Sentient ArtifactとBWMM間の通信接続性を 考慮し，接続不能時にあっても直近に受信している情報を取得することができる．そ の際には状態情報のみならずそれが検出された時間情報も付加される．取得側ではこ の時刻情報を各々の評価基準に従い評価することで，そのまま使用したり，古すぎる 場合には破棄するといった処理を実装することができる．このため，使用としてポー リングを許可しているSentient Artifactに対してはまず始めに直接問い合わせをし，
取得に失敗した場合にはBWMM上から取得する．この一連の処理についてはState クラスが提供するメソッド中でカプセル化しており，利用側は一回のメソッドコール として認識することになる．図（T.B.D.）にこの様子を示す．
3.3 プログラムコード記述例
次にコード断片をもとに空間モデルのプログラムにおける利用について検証する．
■ 特定場所における入退出情報の利用 例えば， 冷蔵庫がある場所での物理オブ ジェクトの入退出を契機として処理を実行する には以下のように記述する．た だし，wは任意の名前空間を持つ単位空間である．また，DetectionListenerを 実装したオブジェクトはこのコード断片が書かれているオブジェクトそのもの
（this）であるとする．
Listing 1: Locationの取得例
1 Location [] loc = w . getLocationsByType (" refrigerator ");
2 for ( int i = 0; i < loc . length ; i ++ ) { 3 loc . addDetectionListener ( this );
4 }
この手順は冷蔵庫がある場所に行き，そこでの他の物理オブジェクトの動きを 見張るのと似ているといえる．また，通常のイベントベースプログラミングと 同様に，登録した状態の変化をイベントとして受信するには以下のような記述 が必要となる．
Listing 2: 位置変化イベントの取得例
1 Location [] loc = w . getLocationsByType (" refrigerator ");
2 public void locationChanged ( LocationChangeEvent lce ) { 3 String id = loc . getDetectedID ();
4 String detector = lce . getDetectorID ();
5 6 }
■ 状態変化の利用 次に， 入り口にある全てのイスの着座状態の変化を利用す る には以下のように記述する．ただし，attrは検索属性を表すHashtableを それぞれ表し，StateListenerを実装したオブジェクトはこのコード断片が書か れているオブジェクトそのもの（this）であるとする．
Listing 3: Artifactの取得例
1 Artifact [] a = w . getArtifactByLocation (" chair ", " entrance ");
2 for ( int i = 0; i < a . length ; i ++ ) { 3 a. addStateListener (" seat_state ", this );
4 }
予め取得されたイスを表すArtifactオブジェクトを，paraは発行コマンド名お よび引数を表すHashtableオブジェクトである．コマンド処理を受け付け（アド レス，ポート番号，処理プログラム名）を同時にBWMMに登録するため，開 発者側でそのような低レベルの情報を設定する必要はなく，純粋にコマンド種 別（1行目），コマンド名（3行目），コマンド引数（4行目）を指定するだけで 良い．
Listing 4: コマンド発行例
1 Actuator act = chair . getActuatorByType (" vibration ");
2 Command c = actuator . getCommand ();
3 params . put ( CommConstants . COMMAND , " vibration_on ");
4 params . put (" duration " , "10000");
5 command . execute ( para );
4 現場指向の開発支援ツール： Bazaar Application devel- oper’s support environment （ BASE ）
4.1 導入
4.1.1 新たなる開発手法の提案
これまでのユーザ支援型のアプリケーションおよびサービスは汎用的なものがほと んどであった．例えば，携帯電話の位置情報からその近隣のスポットを教えてくれる サービスがある．これは，「ユーザは，契約済みの携帯電話を携帯し，電源を入れてい る」というたったこれだけの条件さえ満たせば，どのユーザにもサービスを提供でき る．しかしながら，近い将来到来するであろうSentient Artifactが普及した世の中で は、アプリケーションを導入する場所毎に利用できるSentient Artifactは異なり，さ らにユーザ毎にカスタマイズされたアプリケーションが無数に登場すると考えられる．
そういった世の中になった場合，アプリケーションは汎用的なものよりも，アプリケー ションを導入する各現場一つ一つに合わせた非汎用的なものが必要になると考えられ る．とはいえ，エンドユーザが自分の家にあるSentient Artifactの仕様を知り，ミド ルウェアを理解して，アプリケーションを開発するとは考えにくい．そこで，将来必 要とされるのが，Sentient Artifactを統合利用するアプリケーションの開発者である．
本研究では，この開発者を支援する開発手法として「現場指向開発」を提案する．
4.1.2 現場指向開発の必要性
ここで1つのサンプルシナリオを挙げて，現場指向開発の必要性を示したい．図
(T.B.D.)のように，机と椅子，ライトがある勉強用の小部屋があったと仮定する．各
モノの機能は表??のとおりである．
モノ コンテクスト アクチュエータ 机 前に人がいるかどうか 警告アラーム 椅子 座っているかどうか バイブレーション ライト 明るさ ライト点灯／消灯
表2: サンプルシナリオにおけるモノの機能
まずは，上記のSentient Artifactの情報とその部屋の様子を写した写真をもとに，
現場とは違う場所（e.g. オフィス）でアプリケーション開発を行う．本論文では，こ のような開発スタイルを「机上開発」と呼ぶことにする．この空間に導入できるアプ
使い，明るさのレベルがある一定の閾値を超えたら，ライトのアクチュエータである
「点灯をさせる方法が考えられる．
では，このアプリケーションを実際の現場に導入してみたとする．しかし，その部 屋を使うユーザには不評であった．ユーザは「まだ明るいのにライトがついてしまい，
電気代がもったいない」と言う．どの程度暗くなったらライトを点灯させるかは，最 初にユーザと共にキャリブレーションを行ったはずであるのに，いったいなぜであろ うか？このシナリオで考えられることとして，机の位置とライトの位置の明るさが異 なることが挙げられる．実際現場に行ってみると，ライトのある場所は壁際なため，
日光が当たらないが，机の位置は入り口から日光が当たることが確認された．上記の 例でもし現場にあらかじめ出向いていたら，導入後のトラブルは未然に防げたかもし れない．
では，Sentient Artifactの情報とその部屋の様子を写した写真だけでなく，あらか じめバーチャル環境をオフィスに構築し，アプリケーション開発を進めるのはどうで あろうか？将来，Sentient Artifactが普及した世の中になった場合，前述のとおり，要 求されるアプリケーションは多様化し，各環境にあったアプリケーションを開発する ことになると予想される．それを考えると，毎回バーチャルな環境を整えるより、現 場に出向いてアプリケーション開発を行ったほうが，より効率的であると考えられる．
こうした問題の解決策として，「現場指向開発」を提案した．これは，アプリケーショ ンが導入されるSentient Artifactのある現場に出向き，現場の環境・状況を理解した した上でアプリケーションを開発する手法である．そのため，アプリケーション開発 の1から10まで全ての工程を行うわけではなく，現場では現場特有の状況・問題等さ え確認できれば，アプリケーションの核となる部分の開発は開発者のオフィスなどで 落ち着いて行ってもらうことができる．
4.1.3 開発支援ツールの必要性
では，現場指向開発を実際に行う際に，現状のノート型PCのような持ち運び可能 な開発端末のみを持参すればよいのだろうか？やはり，机上開発と同様に各Sentient
Artifactの仕様書などの資料も必要になってくる．しかし，資料は紙に印字したもの
であれば結構な重量になり，持ち運びに不便になる．開発端末の中にファイルとして 資料を入れると，開発端末の小さな画面上で開発スペースと資料を交互に見ながら開 発を行うことになり，逆に効率を低下させてしまう．このように現場指向開発を導入 する上でいくつかの問題が想定されることを踏まえ，開発支援が必要となると考えて いる．
また，前章で述べたBazaarでは，物理世界に存在する一部の概念についてはオブ ジェクト指向的な手法により実装されているものの，具体的な種別や値を表す属性の 取得や設定に関しては， key-valueペア におけるset(key, value)，およびget(key) メソッドを介して行う．これにより拡張の柔軟さを入手できる一方，型チェックを受 けられずに以下に挙げるようなミスをコンパイル時に検出することができなくなる．
• ミスタイピング：文字列の入力間違え．
• 入力忘れ：必要な情報の入力し忘れ．
• 入力範囲の逸脱：日付や時刻のような入力範囲の逸脱した入力．
様々な属性が存在しその種類は増加していくことが考えられるユビキタス環境にお いて，柔軟性は重要な要素である．よって，柔軟性を維持しつつ，開発の効率と頑健 性を高めるために属性情報の入力を支援するツールが必要となる．
4.2 BASEの設計
本節では，前節で明らかになった現場指向開発，および現場指向開発における開発 支援ツールの必要性を踏まえ，ツールの設計について述べる．
本研究で開発する開発支援ツールは，前述のBazaarを用いたアプリケーションの開 発を手助けする環境であるという意味から，Bazaar Appliction developer’s Support Environment（略称，BASE）と名づけた．BASEは開発者が使用するノートPCの ような端末上で動作する．以下に開発支援ツールに必要となる機能を挙げる．
■ Physical Object Viewer (POViewer) 開発者が現場に着いて最初に行う 作業は，現場付近にあるSentient Artifactの確認であると考えられる．その際，
開発PC上に付近のSentient Artifacの写真が写し出されれば，確認しやすいと 考えている．本機能は，付近のSentient Artifactの写真を表示する機能である．
■ Object Information Viewer（OIViewer） 机上開発で必要であったSen-
tient Artifactの資料の代わりとなるべく，取得できるコンテクストやアクチュ
エータといった仕様および詳細情報が一目でわかるようにする必要がある．本機 能は，POViewerに表示された写真を選択すると，選択されたSentient Artifact のID，形式，所有者，取得できるコンテクスト，アクチュエータといった情報 が表示される機能である．
■ Code Wizard Bazaarの利用をより容易に，そしてより頑健なものにするた
め，Bazaar特有のコードの入力を支援する必要がある．本機能は，Bazaarにア
クセスするためのコードをパターン化しておいたものから，開発者はどのコー ドを入力したいかを選択し，選択されたコードパターンにおいて使われる値や 変数，設定などをウィザードより選択していくことでコード入力ができる機能 である．
■ Actuator Tester 開発者はアクチュエータがどのような振る舞いを見せるか，
4.3 実装 4.3.1 概要
今回，BASEは次に挙げる理由から，Eclipse（付録参照）のプラグインとして実装 した．
• BazaarがJAVAで実装されているので，JAVAエディタと互換性を持たせる必 要があった．
• 高機能統合開発環境として非常に多くの開発者に認知され，使用されている．
• Eclipseはプラグインを導入することで容易に拡張できる．
BASEとEclipseプラットフォーム、およびBazaarとの構成関係は図??のように なっている．
図7: BASEの構成
4.3.2 Sentient Artifactの検出法
BASEは開発端末付近のSentient Artifactを検出する方法として2つのタイプを用 意している．これは，使用環境によって検出法を使い分けることによって，よりBASE の機能を活かせるからである．各タイプの特徴と適応環境については次のとおりで ある．
図8: BASE画面例
■ タグ検出型 開発端末に無線タグ読み取り器を取り付け，その読み取り器が検出 したSentient ArtifactをPOViewerに表示する方法である．このタイプは，ま だ無線タグ読み取り器の最適な設置位置を決めかねているロケーションにおけ る使用に有用である．IDEとしての機能の他に，開発端末にある読み取り器が 読み取ったSentient Artifactの一覧が一目でわかるため，環境内の無線タグ読 み取り器を部屋のどの位置に置けば最適かを検討することもできる．一方で，開 発用PC以外に無線タグ読み取り器を持ち運ばなければならないため，携帯時 の不便さがある．なお，本研究で用いた無線タグ読み取り器はSpider（付録参 照）というものである．
■ 環境依存型 開発端末に無線タグを取り付け，開発端末も一種の Sentient Ar-
tifact としてBazaarに扱ってもらい，現場に配置された無線タグ読み取り器を
用いて，開発端末のタグと同一の読み取り器（ロケーション）に検出されてい るものを付近のSentient ArtifactとしてPOViewerに表示する方法である．こ のタイプは，開発用PC以外は必要ないため，携帯性は保たれるが，タグ検出 型で実現されるような付加機能は期待できない．
図9: Code Wizard画面例 4.3.3 Physical Object Viewer (POViewer)
あるSenteint Artifactに付いたタグを検出すると，Bazaarによって提供されるメ ソッドgetArtifactByID(String ID)を用いてSentient Artifactの情報を取得し，その 情報の中の属性である image から画像のURLを取得し，画像を表示している（図
??参照）．Sentient Artifactの1ページに表示される数を4に設定しており，付近に 存在するSentient Artifactが4つを超えると2ページ目以降に表示される．
4.3.4 Object Information Viewer（OIViewer）
Sentient Artifactの画像がクリックされると，そのSentient ArtirfactのIDをキー としてPOViewerと同じくgetArtifactByID(String ID)によってSentient Artifactの 情報を取得し，テーブルツリー形式で展開している（図??参照）．各パラメータはク リックされると，そのパラメータに関するCode Wizard（次項参照）を開始できる．
4.3.5 Code Wizard
OIViewerのあるパラメータをクリックされると，Bazaarにアクセスするためのコー
ドをパターン化しておいたものから，そのパラメータに関するコードを選び，一覧を
図10: Actuator Tester画面例
ウィザードに表示させる．この1枚目のウィザードで入力したいコードを選ぶと，2 枚目では1枚目で選ばれたコード内にあるメソッドを呼ぶインスタンスと参照を代入 する変数を設定する．3枚目では，取得オブジェクトに設定可能な状態変化が起こっ たときに通知してもらうためのListenerが表示され，設定の有無を決めることができ
る．OKならば，Finishボタンを押し，エディタのカーソルがある位置に出力される．
実際の出力例をListing ??に示す（指定IDのArtifactオブジェクトを取得し，その 状態変化を通知するためのStateListenerを登録する場合）に示す．
Listing 5: コード出力例1
1 Artifact artifact = world . getArtifactByID (" HHREPWI ");
2 artifact . addLocationListener ( this );
また，Listing??のようにListener登録を選択した場合は，Listenerインターフェー スの実装（implements節の追加とスケルトンメソッドの出力）も自動で行う．
アクチュエータに関するコード出力はActuator Tester（次項参照）の機能の一部と して実装する．
4.3.6 Actuator Tester
OIViewerからアクチュエータのコマンドを選択することによって，現場にてその
コマンドが仕様どおりの挙動を示すか否かを確認することができる．また，気に入っ たアクチュエータは，テスト後，そのままの流れでコマンド起動部のコードを入力す ることが可能である．既に動作確認済みのアクチュエータの場合は，テストを省略す ることも可能である．
実装はCode Wizard同様ウィザード形式（図??参照）とし，まず1枚目ではコマ ンド起動時に必要な引数の入力と，アクチュエータテストの有無を選択する．ここで テスト有りを選択しNextを押すと，アクチュエータの動作が始まり，ウィザードは2 枚目へ遷移する．2枚目には出力するコードが表示される．動作とコードの確認が済
み，OKならば，Finishボタンを押し，エディタのカーソルがある位置に出力される．
実際の出力例をListing ??に示す．
Listing 6: コード出力例2
1 long time ; // TODO Initialize this variable . 2 int level ; // TODO Initialize this variable .
3 Actuator actuator = bag . getActuatorByType (" vibration ");
4 Command command = actuator . getCommand ();
5 Hashtable params = new Hashtable ();
6 params . put ( CommConstants . COMMAND , " vibration ");
7 params . put (" time " , new Long ( time ));
8 params . put (" level " , new Integer ( level ));
9 Response response = command . execute ( params );
5 評価と考察
5.1 評価基準
本研究において、評価は 実際にBASEを多くの方々に使っていただき，その感想 や意見をまとめる， BASEを使う前と使ったときにどのような手順の違いがあるの かを比較する，などの方法が考えられる．しかしながら、Bazaarというミドルウェア を理解し，かつEclipseの使い方を習得している者が周りにごく少数しか存在しない ため，前者（ ）の評価基準は取り入れることができなかった．よって，後者（ ） の評価基準を用い、アプリケーション開発プロセスを比較することとする．
また，「現場指向開発」という開発手法としての評価と，コード入力支援を中心とし た「開発支援ツール」としての評価の大きく2つに分けて述べていく．
5.2 評価用サンプルシナリオ
傘忘れ防止アプリケーションを開発するシナリオを用いて，現場指向開発の手順と BASEの有用性を述べたい．
傘忘れ防止アプリケーションの開発をしようとしている開発者がいると仮定する．
開発者はまず傘がある玄関に行ってみる．BASEのPOViewerには次のSentient Artifactが表示された．
• 傘立て
• 玄関ドア
• 鏡
続いて，それぞれのOIViewerより詳細情報を見ていく．
傘立ては傘がセットされているか否かをコンテクストとして保持している．また，
アクチュエータとしてライトがある．実際にActuator Testerから傘立てのアクチュ エータを実行してみる．すると，3色のライトが点滅することがわかった．これは，傘 を忘れていることをユーザに通知するのに使えそうである．
玄関ドアはドアの開閉をコンテクストとして保持している．アクチュエータはスピー カより警告音が鳴る．これも実際に実行してみると，玄関を出ようとしている者にも 聞こえるボリュームで警告音を発した．これも利用することにした．
鏡は人が前にいるかどうかをコンテクストとして保持し，アクチュエータはディス プレイとして様々なコンテンツを表せるようである．しかし，鏡のある位置にユーザ が検出されても，玄関を出るか分からない上，またアクチュエータのディスプレイも 傘忘れを通知するには不向きである．今回のアプリケーションには使うことができな
一方，ユーザの外出の検知はどのようにすべきか？身の回りのものが多いユーザの 部屋に行ってみることにする．すると，鞄を発見した．鞄はユーザが出かける際，ほ ぼ確実に持っていくものである．そこで，この鞄が「玄関内」を示すロケーションか ら「玄関外を示すロケーションに移動したら，ユーザが外出したとみなすこととする．
また，OIViewerから鞄の詳細情報を見ると，アクチュエータにバイブレーションが
あることが分かった．鞄は一番ユーザに近接しているものなので，これは忘れ物を通 知するのによいと考えられる．
続いて，玄関の外に行き「玄関外」にあるモノを探すと，ライトがあった．よって，
ライトが検出されるロケーションを「玄関外」とする．同様に「玄関内」にあるもの の中でロケーションの象徴となるものを探す．ドアは「玄関外」と「玄関内」とのロ ケーションを隔てるものであるため，両方のロケーションに検知することが考えられ るため，ドアはロケーションの象徴にはできない．そうすると，傘立てと鏡のどちら になるが，傘立ては必ず玄関にあるものだが，鏡は移動させられてしまう可能性が考 えられる．よって，傘立てが検出されるロケーションを「玄関内」とする．
以上のことから，アプリケーションのロジックは以下のように決まる（図（T.B.D.） も参照のこと）．
「鞄が傘立てと同一のロケーションから，ライトと同一のロケーションに移動したら，
傘立ての状態を調べ，傘がセットされていたら，鞄のバイブレーション，玄関ドアの 警告音，傘立てのライト点滅といったアクチュエータを起動させる」
5.3 現場指向開発の評価
本研究では，現場指向開発と従来の机上開発とを比較することで，評価および考察 としたい．
まず1つ目に挙げられるのは，アプリケーション開発後，現場へ導入するときのの 導入現場の把握が可能になることによって，導入後の調整の手間が減少した．これは，
現場指向開発の必要静のところでも述べたが，現場特有の障害をアプリケーション設 計前に確認することができ，そういった障害を未然に考慮に入れることができるとこ ろが大きな利点といえる．
2つ目に挙げられるのは，現場に行くことでアプリケーションの核となるSentient
Artifact以外も視野に入るので、アプリケーションのロジックの幅が広がったことで
ある．前節のサンプルアプリケーションの例でも開発者は玄関に注目はしていたもの の，ユーザ（アプリケーション依頼者）の部屋に鞄があることを知り，さらにその鞄に バイブレーションというアクチュエーションがあることも把握でき，アプリケーショ ンに導入することができた．このように，アプリケーション開発者があらかじめ注目 していたSentient Artrifact以外にも，現場に行くことにより一見関係ないと思われ るものもアプリケーションの機能および性能向上に貢献することがあるのである．
5.4 開発支援ツールの評価
本研究では，BASEを利用したときとしないときとを比較することで，評価および 考察としたい．
隠れたSentient Artifactの発見
POViewerがあることによって，現場に行ってもなお位置の関係で見ることができ
ないSentient Artifactの存在を知ることができる．これにより，ロケーションシステ ムが検知できるところにさえあれば，例えたんすの中にしまわれていようが，何かの 下敷きになって見えなかろうが，Sentien Artifactを見つけ出すことができ，その機 能を十分に引き出すことができると考えられる．
コード入力支援による開発者の負担減
Code WizardおよびActuator Testerのコード出力機能があることによって，アプ リケーション開発者が入力するコード数が大幅に減少した．本研究で実装した開発支 援ツールの大きな目標として，コード入力の支援というのがあったので，当然の結果 ではあるかもしれない．しかしながら，ミドルウェア固有のインタフェース部分を自 動で出力してくれるだけで，アプリケーション開発者はそのアプリケーションのロジッ クの設計，実装に集中できる点は貢献度が大きいといえる．実際に，前節のサンプル アプリケーションで作成したプログラムを付録に添付するが，行数にして約21％の コードを出力している．
GUIの非直感性
GUIの面では，Bazaarがコンセプトとして「利用の直感性」を掲げているのに，開 発支援ツールでは直感的なデザインをすることができていない．本ツールの対象はエ ンドユーザではなく，あくまでアプリケーション開発者であるが，もう少し分かりや すいデザインとすることが必要となる．
コード出力パターンの不十分さ
出力されるコードパターンが十分ではなかった．しかしながら、この問題の解決策 として，ただコードパターンを増やすというのはあまりよいものとは言えない．これ はコード入力補助であまり深いところまでコードパターンを決めてしまうと，汎用性 に欠けてしまうからである．この汎用性と開発者側のコード入力負担のトレードオフ について，再検討する必要がある．
6 将来課題
6.1 拡張機能
6.1.1 パラメータチェック
4.1.3でユビキタス環境における柔軟性を維持するため，キー・値ペアの管理を行
い，これにアプリケーション開発の頑健性を保つため開発支援ツールを開発した．し かしながら，今回開発した開発ツールは入力支援はするものの，属性文字列チェック といったミスを見つけ出すことはしていない．BASEでは，コード入力支援はしてい るものの，最終的なプログラムを作成はアプリケーション開発者に任せている．その ため，もしコード自動生成部分の属性を示す文字列を誤って編集してしまった場合は，
そのミスを修正することができないまま，コンパイルを通ってしまう．こうしたこと を防ぐために，BASEの側で文字列チェック等の機構を持たせたいと考える．
6.1.2 使用履歴
本機能は，BASE上に表示されたSentient Artifactがどういったアプリケーション に使用されたか，または他のSentient Artifactと組み合わさってどういうコンテキス トを抽出したか等を記憶しておき，今後のアプリケーション開発時に参考にしてもら うものである．
前述のとおり，近い将来にSentient Artifactのようなインテリジェンスなモノが増 加したときに，アプリケーション開発の需要は高まることが予想される．すると，ア プリケーション開発者の絶対数が足りなくなっていくであろう．そうなった時に，「熟 練開発者」がアプリケーションを開発した時のサンプルや使用履歴があれば，「見習い 開発者」であったとしてもどのようにSentient Artifactを統合してよいかを迷わなく てすむと考えられる．
6.1.3 コードパターンの追加
現状のBASEで扱っているコードパターンは，Bazaarに備えられたAPIがほとん どである．しかし，基礎評価において，よりパターンが必要なことが検証された．例 えば，プログラム??の○行目であるが，このようなfor文の連続は開発者にとってか なり負担になる．ある程度予想される繰り返しに関しては，BASEの側で入力支援す る必要がある．
6.2 Graphical User Interface
BASEは，物理空間のモノの情報と，Bazaar上に展開されるアプリケーション作 成をサポートすることを最大の目的として作成したため，機能面は考慮に入れたが，
ユーザインタフェースの観点からすると非常に未熟さがある．EclipseではGUI用ツー ルとしてSWTを用意している．BASEでもSWTを利用してGUIを構築したが，調 査不足もあり，使用者の使いやすいものとは言えない．今後は，SWTを学び，より 使用者の立場に立ったユーザインタフェースを構築したい．
6.3 他のプラットフォームへの対応
本研究では，同研究室内において開発されたBazaarというミドルウェア上で開発 支援ツールを実装した．しかしながら，今後コンテクスト抽出のためのミドルウェア およびプログラミング言語が開発される可能性は十分にある．そこで，「現場指向の開 発支援ツール」も既存のものを含めた複数のプラットフォームに対応できなければな らないと考えている．本研究で選択した基盤となる統合開発環境はEclipseであるが，
これはJAVAのみならず，プラグインを追加することで他のプログラミング言語にも 利用することができる．この利点を活かし，「現場指向の開発支援ツール」のマルチプ ラットフォーム化を実現する方法を検討したい．
7 関連研究
7.1 Ubiwise
Ubiwiseでは，空間内のモバイルデバイスの情報を計算機上に取り込み，2Dまたは
3Dによる表示技術を用いて，ユーザ操作の空間内の影響を把握することを試みてい る．このような手法は，全く未知の空間やデバイスを扱う場合には有効である．しか し，高精度のシミュレーションモデル構築にはコストがかかったり，完全に対象空間 を再現することは不可能であるため，概設の空間に対しては現場への移動コストを考 慮しても，BASEが提案する現場指向開発が適していると考える．
8 結論
本研究では，Sentient Artifactの統合を支援する開発環境を提示した．著者が感じ ているのは，人間の状態を抽出することの難しさ，もっと言ってしまえば，人間の状 態を表現するセマンティックスを決めることの難しさである．ユビキタスコンピュー ティングの分野において，このテーマはおそらく永遠に明確にはならないと考えてい る．であるならば，アプリケーション開発者が過去の例を参考にしながら，状態抽出 法をおのおので作成していけばよいのではないだろうか．そして，その状態抽出の正 しさを決めるのはそのアプリケーションのユーザである．ユーザに支持されるアプリ ケーションに使用された状態抽出法は生き残り，そうでないものは淘汰されていく．
こうして切磋琢磨しながら，状態抽出法も徐々に向上してゆけばよいと思っている．
状態抽出のためのSentient Artifactの統合において，著者が提案する現場指向開発，
およびBazaar上で動作する統合開発環境のBASEが開発者の手助けになることを期
待したい．
参考文献
[1] K. Fujinami, et al. AwareMirror: A Personalized Display using a Mirror. InPro- ceedings of International Conference on Pervasive Computing, Pervasive2005, 2005 (to appear).
[2] K. Fujinami and T. Nakajima. Towards System Software for Physical Space Applications. In Proceedings of ACM Symposium on Applied Computing(SAC) 2005, March 2005. (to appear).
[3] Eclipse Foundation. http://www.eclipse.org/.
[4] Chen, G. and Kotz, D.: A Survey of Context-Aware Mobile Computing Re- search, Technical:
[5]
謝辞
付録
Eclipse
Eclipseは，ワークベンチと呼ばれる実行環境，JAVA開発機能であるJDT（Java Development Tools），JAVAデバッガ，Eclipseプラグインを開発するためのライブラ リ群，ヘルプ・ドキュメントなどが含まれており，そのままJAVA統合開発環境とし て利用できるオープンソースの統合開発環境（以後，IDE）である．元々はIBMが自 社のアプリケーション・サーバ用の開発環境として1999年4月に開発を開始したもの であるが，2001年11月にオープンソースコミュニティにソースが寄付され，Eclipse プロジェクト（http://www.eclipse.org/）で開発が続けられている．
Eclipseは，開発者のニーズに応じて柔軟に活用できるよう設計されている．以下
に，その特徴を挙げる．
■ 製品版IDEと同等の充実した開発機能 コード生成（補完）機能，ステップ実 行によるデバッグ機能，検索機能，ビルド，テスト機能など，IDEに必要な機能 はほぼ網羅されている．さらに，コードのリファクタリング機能，バージョン 管理システムCVSとの連携機能など，大規模開発にも対応している．
■ プラグイン・アーキテクチャ EclipseはJAVAの開発環境も同梱されているた め，JAVA統合開発環境と認識されがちであるが，それはEclipseの機能の一部 でしかなく，Eclipseの特徴の1つであるプラグイン機能を使って実現されてい るものになる．
JAVAの開発環境は，JDTプラグインとして初めから提供されている．他に も，C／C++プラグインや，PHPプラグインなどを導入することで各種言語の 開発環境になる．また開発言語にとどまらず，XMLエディタ，データベースメ ンテナンス用のプラグインなども存在するため，それらを導入することで，多 彩な開発作業環境を自由に構築することが可能になっている．
さらに，自身でプラグイン開発ができる環境（Plug-in Development Environ- ment）も存在するため，パワーユーザにとっては魅力的なものだといえる．プ ラグインはJAVAを用いて開発し，開発方法についてはヘルプに詳細な記述が ある．
■ 動作の速さ Eclipseは，独自のネイティブコンポーネントSWT（Standard Widget Toolkit）を利用しているため，Swingを利用したGUIを用いたIDEよ り軽快に動作する．
■ 柔軟なライセンス内容 Eclipseは，CPL（Common Public License）と呼ばれ るライセンスで配布されている．これは，以前IBMが利用していたIPL（IBM Public License）を，一般的に利用できるように書き直したライセンスで，OSI
（Open Source Initiative）にも，オープンソースライセンスであると認定されて いる．
このCPLは，LGPL(GNU Lesser Gereral Public License)と似た形式を取っ
ており，Eclipse自身を改造した場合はその部分のコードを公開する必要があり
ますが，プラグインとして機能追加を行う場合は，プラグインの部分のソースを 公開する必要はなく，ライセンス上の制限（商用利用不可など）もない．そのた め，IBMはもちろんのこと，Rational，QNXなど，様々なベンダからEclipse に独自のプラグインを追加した商用の開発ツールが出ている．
また，製品開発者は，第三者に特許侵害を主張されたとしても，それに対す る一切の責任を放棄している，といった特許に対する免責事項が含まれている ことも注目すべき点であるといえる．
図11: Eclipse画面例
