提案 DSML の記述能力検証

また，図4.7の修正後のモデルは，図4.6の修正後のモデルとネットワーク情報か ら自動生成されるモデルに等しい．Node-levelモデルを直接変更した場合には，モ デルへの変更箇所が複数のノード・役割間の関連に分散するところを，Group-level モデルを変更した場合には変更箇所がリーダ，メンバの配置条件に集約されてお り，かつ得られる結果は同じであるといえる．

更に，当該アプリケーションでは，プロトタイプの実装ではCTP用い，実行結 果から患者ノードと中継ノード間のルーティングプロトコルを変更している．す なわち，通信方式の変更という再設計を実施することで品質調整を行なっている．

この様な変更についても，Node-levelモデルにて，Sending/ReceivingTaskのプ ロトコルのパラメタを変更することで，モデル上に設計の変更を反映可能であっ た．ただし，独自のプロトコルを用いる場合には別途プロトコルの実装を用意す る必要がある．このように，患者状態監視アプリケーションの開発においても通 信方式や役割，タスク割り当ての変更が可能であり，これらの変更はプロトタイ プから自動生成されたモデルに対して行えるため，要件2，3を共に満たしている．

その他，表4.1に挙げたアプリケーションについても同様に検証を行ったところ，

データフローからのプロトタイプ生成，通信方式やタスク割り当ての変更による 品質調整が実現可能であった．品質調整時には，プロトタイプ生成時に同時に自 動生成されたGroup-level，Node-levelのモデルを再利用可能であることも確認し た．ただし，幾つかのアプリケーションにおいて，一部機能や品質調整項目は記 述不可能であるという結果を得た．これについては4.2節にて詳述する．

表 4.2: 記述能力検証に用いたアプリケーションと記述不可能な機能

アプリケーションの種類 記述不可能な機能 記述不可能な品質調整項目

歴史的建造物監視 なし 時刻同期機構

橋梁監視 なし 時刻同期機構

火山活動監視 イベント通知 時刻同期機構

火災監視 なし なし

気候監視なし なし MACプロトコル

患者状態監視 なし なし

フェンス監視 イベントハンドラ，イベント通知 なし

また，品質調整に関わる項目については，時刻同期アルゴリズムとMACプロ トコルの指定については本研究のDSMLでは記述出来ない，という結果であった．

これらの項目は，アプリケーションが実行されるOSやミドルウェアといったプ ラットフォームに付随する項目である．一方，送信データの圧縮，ネットワーク トポロジ・ルーティングプロトコルの指定やノードごとの異なる役割の割当は記 述可能であるという結果が得られた．

このケーススタディで示したように，WSNアプリケーションとして最も一般的 な，データ計測・送信を定期的に実行するアプリケーションに対しては，すべて の機能が表現可能であった．また，イベントに基づく実行を含むアプリケーショ ンでは，イベントハンドラ，イベント通知の機能を表現できないという結果であっ たが，データの計測や移動平均といった時系列データに対する集約処理は表現可 能である，という結果を得た．更に，品質調整については，プラットフォームに 組み込まれる様な項目は記述不可能であったが，通信方式や個々のノードへの役 割の割当は記述可能である，という結果を得た．

本節では提案する開発プロセスの有用性について，以下に基づき議論する．ま ず4.2節で述べたDSMLの記述能力についての検証結果を受け，その有用性を述 べる．次に，自動変換の有用性について述べ，開発時に生じるモデル間の一貫性 の問題と自動変換によるサポートについて詳述する．その後，本論文では対象と しなかった範囲や制限について言及し，最後に4.1節の結果に基づき本開発プロセ スが第1章で述べた要件を満たしているかを含め，本開発プロセスの有用性につ いて記す．

5.1 DSML の記述能力

表4.2では，実際のWSNアプリケーションを本研究おけるDSMLを用いて記述 し，求められる機能が表現可能であるかを検証した結果を示した．本研究のDSML で記述出来なかった機能は，イベントに基づく動作の変化，近隣ノード及びベー スステーションへのイベント報告であった．イベント検知を行い，イベントが検出 された場合には別の処理を行うといった，イベントに対応する動作を表現するイ ベントハンドラは記述不可能であった．また，近隣ノードやベースステーション へイベントが検知されたことを報告といったイベント通知もサポートしていない．

これは，本研究では，定期的なデータ計測・送信を行うアプリケーションを対象と してDSMLの設計を行なっているためである．より広範なアプリケーションに対 応するためにも，今後DSMLをこれらの機能を表現可能なよう拡張する必要があ ると考えられるが，現状のDSMLでも，WSNアプリケーションとして最も多く 見られる，定期的なデータ計測・送信を行うアプリケーションに求められる機能 は表現可能であるため，この種のアプリケーション開発には有用であるといえる．

また，今回ケーススタディにて対象としたアプリケーションでは，データ品質の 改善のため，アプリケーションとしての機能の他に，特定の時刻同期アルゴリズム やMACプロトコルを採用しているケースが多く見られた．本研究のDSMLでは，

時刻同期アルゴリズム，MACプロトコルの指定を表現することはできない．これ は，時刻同期やMACプロトコルはOSやミドルウェアといったプラットフォーム レベルでサポートされる部分であり，特定のプラットフォームに対して開発を行う アプリケーション開発者が関知する部分ではない，と考えているためである．時刻 同期アルゴリズム，MACプロトコルの変更を行いたい場合には，プラットフォー

ムの管理者が，必要に応じてアプリケーションが動作するプラットフォーム側を 変更することで対応可能である．

更に，ケーススタディにて，品質調整にあたり，通信方式や個々のノードへの役 割・タスクの割り当てを変更する方法は，Group-levelモデルにおける変更を行う

方法とNode-levelモデルにおける変更を行う方法の2通りがあることを確認した．

Group-levelモデルに対する変更としては，グループ内のリーダ・メンバ間の通信

方式の変更，リーダ・メンバの配置条件の変更が，Node-levelモデルに対しては，

送受信タスクに分散する通信方式の変更，ノード・役割間の割り当て関係の変更 がそれぞれ可能であることを，ケーススタディにて示した．Group-levelモデルに 対し変更を加える場合，Node-levelモデルに変更を加える場合と比べ，変更箇所が 分散せず，より簡潔に変更をモデル上に反映可能であるといえる．更に，変換規 則により，Node-levelモデルに対して変更を加えた場合と同等のモデルを自動変換 で得られるため，同様の結果をより簡潔な記述で得られたといえる．しかし，個 別のノードの位置に基づく役割の割り当てのように，配置条件などの変更を簡潔 に表現出来ない場合には，Node-levelモデルに対する変更を加えることも有効で あると考えられる．このように我々のDSMLでは，通信方式や役割・タスクの割 り当てを，マクロな視点と個別ノードの視点の双方から設計可能であり，細やか な品質調整に有用であると考えられる．

5.2 自動変換の有用性

自動変換の実現のため，本研究で定義したモデル間の変換規則の設計について は3.3節にて，実装したシステムについては3.5節にて詳述した．この変換規則と 実装により，開発者は作成したモデルよりも抽象度の低い下位のモデル及び実装 を自動で得ることができる．例えば，Dataflow-levelモデルを入力とした場合には，

実装だけでなくGroup-level，Node-levelモデルも生成する．これにより，開発者 は後の品質調整時に自動生成されたモデルに変更を加えるといった再利用が可能 である．変更が加えられたモデルは，再度自動変換により変更が反映された下位 のモデルと実装を生成する．このように，度々実行される変換という工程を自動 化することにより手動で行った場合に起こりうる誤りの混入が排除される．よっ て，プロトタイプを用いたWSNアプリケーション開発プロセスにおいて，変換規 則による自動変換は有用であるといえる．ただし現状の実装では，ある抽象度の モデルに変更を加えたのち，そのモデルより上位のモデルに変更を加え自動変換 を実行すると，元のモデルに加えた変更が上書きされ消えてしまう．この問題に 対しては，モデルに加えた変更履歴を記録し保持することで対応可能であるため，

今後実装し対応する予定である．

このように提案する開発プロセスでは，複数のDSMLで記述されたモデルを扱 い，開発の中で任意のモデルに対して変更を加えていく．このような開発を行う場 合，開発中に保持するモデルの間で一貫性が崩れることが考えられる．例えば，図