インタラクティブソフトウェアの自動生成に関する研究
M2014SE008 吉川 翔平
指導教員：野呂 昌満

はじめに1ることを目的として，共通アーキテクチャはアスペクト指向アーキテクチャとして定義した (図 1)．共通アーキテク

インタラクティブソフトウェアの開発効率の向上を目的

チャは，1) MVC コンサーン，2) UI コンサーン，3) ビジとしてプログラムの自動生成が利用されている [4]．単一ネスロジックコンサーン，4) データアクセスコンサーン，

ソース開発を支援するクロスプラットフォーム開発環境においても自動生成技術は実用化されているが，これらは主

5) イベント管理コンサーン，6) 画面構築コンサーン，7)
画面遷移コンサーン，8) 表示コンサーンの 8 つの横断的関に MVC におけるビューとモデルのアクション起動を対に心事によって規定されるアスペクトから構成されている．

して適応したものである [3]．我々は，多様な開発環境と多特定の横断的関心事のいくつかを指定して織込むことで，様な実行時環境のすべての可能な組み合わせに対する単一調査したアーキテクチャすべてを生成できる．

モデル開発を目的として，web アプリケーションとスマー
トデバイス等のネイティブアプリケーション (以下，まと2.2モデル駆動アーキテクチャ (以下，MDA) はプラット

めてインタラクティブソフトウェアと呼ぶ) の共通アーキ
テクチャを提案している [5]．

モデル駆動アーキテクチャ

フォームの仕様と PIM(Platform Independent Model) か

本研究の目的は，提案する共通アーキテクチャ上のコンら，プラットフォームに依存した PSM(Platform Specific

ポーネントの自動生成について考察することである．すなModel) を生成するためのシステムのアーキテクチャである．例えば，PIM としては UML 図で書かれたオブジェクトモデル等が想定されている．PSM は具体的なプログラ
ミング言語，例えば Java 等で書かれたコードになる．こわち，アーキテクチャの実現はアプリケーションフレームワークとの認識に立ち，自動生成可能なコンポーネントを同定し，その生成方法について考察する．
一般にアプリケーションフレームワークのホットスポッのさい，プラットフォームは実現に使用するプログラミン

トをカスタマイズするためのコードの自動生成は難しいとグ言語になる．通常，複数の PSM に変換するためのアーされているが，アプリケーションの仕様を与えて自動生成キテクチャを定義したものである．

が可能なものも存在する．これらは，アプリケーションの3アプリケーションフレームワークの自動生成

3.1

共通アーキテクチャに基づくインタラクティブソフ仕様からプログラムコードを自動生成できるものと，仕様を与えてアプリケーションフレームワークを生成できるコンポーネントに分類できる (以下，生成されるものをサブトウェアの開発アプリケーションフレームワークと呼ぶ)．すなわち，共共通アーキテクチャに基づく開発では，まず，アプリ

通アーキテクチャのコンポーネントは，アプリケーションケーションの仕様を与え，サブアプリケーションフレームフレームワーク上で，ワークを含むホットスポットコードの一部を生成する．つ• ホットスポットとなるもの

ぎに，ホットスポットカスタマイズコードを記述する．モ

• フローズンスポットとなるもの

デルやビューは典型的なホットスポットであり，開発す• サブアプリケーションフレームワークとなるもの (以下，SAF コンポーネントと呼ぶ)るアプリケーションに依存する．一方，イベントの授受やモデルからのビューの生成はイベント，モデル，ビュー，それぞれの表現形式，すなわち，アプリケーション上でのから構成されることが確認できた．共通アーキテクチャのデータ型が標準化できれば定型コードとしてフローズンス

目的は現存する任意の開発環境で作成したソフトウェアをポットとなる．他方，共通アーキテクチャでは，モデル，任意の実行時環境で稼働させることなので，これら複数のビュー，コントローラ，それぞれを状態遷移機械としてモ環境要因を整理し自動生成について考察するために，モデデル化する．これらの状態遷移機械は SAF コンポーネン

ル駆動アーキテクチャ [2] に着目する．

トであり，UML の状態機械図などから生成可能である．

2

関連技術

2.1

インタラクティブソフトウェアの共通アーキテクチャ

インタラクティブソフトウェアの現存する参照アーキテ
クチャを調査し，プライマリーコンサーンを MVC とした
場合，いくつかの横断的関心事があることを確認した．すべての横断的関心事を内包するアーキテクチャを定義す生成されたアプリケーションフレームワークでは，状態遷移はフローズンスポットとしてコード化され，状態遷移のさい起動されるアクションはホットスポットとなる．さらに，イベント変換に関しては外部イベントと内部イベントの対応を与えればコード生成可能である．この分類を図 1に示す．
まとめると，共通アーキテクチャに基づく開発工程は以下の通りとなる．

図 1 共通アーキテクチャのコンポーネントの分類• 自動生成可能なホットスポットに与えるアプリケーできる．したがって，フローズンスポットコードの自動生ション仕様の記述とカスタマイズコードの自動生成成のプラットフォームはプログラミング言語，PIM はオブ• SAF コンポーネントの仕様記述からのサブアプリケージェクトモデルとなり，PSM は当該プログラミング言語でションフレームワークの自動生成• サブアプリケーションフレームワークのホットスポッ
トを含むホットスポットカスタマイズコードの記述

3.2

共通アーキテクチャのコンポーネントの自動生成

フローズンスポットとホットスポットの一部が自動生成可能であることは，これまでに述べた通りである．共通アーキテクチャの目的を考えた場合，開発環境や実行時環境に関連する要因群が MDA のプラットフォーム特定にいかに関係するかを考察することが鍵となる．SAF コンポーネントを含むホットスポットの一部については，これに加えて，生成系への入力形式も考慮しなけらばならないことがわかった．

3.3

フローズンスポットの自動生成

フローズンスポットコンポーネントと，そのコンポーネ記述されたコードとなる．共通アーキテクチャのコンポーネントのうち，Display Image Constructor を除くすべてのコンポーネントのプラットフォームはプログラミング言語となる．Display Image Constructor に関しては，DisplayImage Constructor が生成する Display Image のビュー定義
形式に依存する．Display Image Constructor の自動生成に関しては，プラットフォームをビュー定義形式とプログラ
ミング言語の 2 つとした MDA を考えなければならない．
以下，プラットフォームが 1 つの MDA を OD-MDA(OneDimentional-MDA，一次元 MDA)，プラットフォームが複数の MDA を MD-MDA(Multi-Dimentional-MDA，多次元 MDA) と呼ぶ．

3.4

ホットスポットの自動生成

サブアプリケーションフレームワークを含むホットス
ポットの自動生成を実現するさいのプラットフォーム，ントの自動生成を実現するさいのプラットフォーム，PIM， PIM，PSM について整理し，表 2 に記した．

PSM について整理し，表 1 に示す．
表 2 サブアプリケーションフレームワークを含むホット
表 1 フローズンスポットの自動生成

基本的にフローズンスポットはアプリケーションの仕様に依存せず，その記述プログラミング言語が決まれば実現

スポットにおける自動生成

SAF コンポーネントである状態遷移機械からの自動生成について考える．状態遷移機械を自動生成するための仕様の入力は UML 状態機械図が適切であると一般的には考えられる．状態機械図を PIM，実現言語をプラットフォームとして MDA を定義するのが一般的であろう．一方で，Excel などを用いて状態遷移表を定義し，それを PIM とすることも可能である．しかし，状態遷移表は状態機械の一表現形式であり，むしろ PSM とすべきである．PSM から PIM への変換は設計またはアーキテクチャ回復と捉えることができる．生成系を設計するさいに使用者の使い勝
図 2 MD-MDA に基づく自動生成手等を考えた場合，使用ドメインに特化した表現を用いる必要性は否定できない．この事情を考慮して，アーキテクチャ回復を逆モデル変換と捉えて考察する．状態遷移機械

図 3 に示す RMDA-MDA は，RMDA と OD-MDA のは MDA と RMDA(Reverse Model Driven Architecture,組み合わせである．図 3 では，赤枠では RMDA による生逆モデル変換アーキテクチャ) の組み合わせで定義できる． 成を行ない，その後，この出力を PIM とした MDA に基以下，このアーキテクチャを RMDA-MDA と呼ぶ．
づく自動生成が行なわれる．

Event Listener も同様に，プラットフォームを定義形式(例えば，Excel で記述したイベント対応表) とプログラミ
ング言語の 2 つとした RMDA-MDA に基づき自動生成可能である．このさい，RMDA では対応表からイベントのオブジェクトモデルを回復し，MDA でそのオブジェクトモデルから特定のプログラミング言語で書かれたコードを生成する．

4

MDA に基づく自動生成の分類
共通アーキテクチャの各コンポーネントについて自動生
図 3 RMDA-MDA に基づく自動生成成を考えた結果，MDA に基づく自動生成は以下の 3 種類に分類できることがわかった．

• OD-MDA• MD-MDA• RMDA-MDA
OD-MDA は PIM とプラットフォームの仕様を読み込
み，PSM を自動生成するためのアーキテクチャである．
MD-MDA は PIM と複数のプラットフォームの仕様を読み込み，PSM を自動生成するためのアーキテクチャである．図 2 は，赤枠と青枠で囲まれた OD-MDA から構成される MD-MDA を示している．赤枠の MDA では，PIMと特定のプラットフォームの仕様を読み込み，PSM を生成する構造を示している構造を示している．青枠の MDA
では，PIM(赤枠の MDA で生成された PSM) と異なるプラットフォームの仕様を読み込み，PSM を生成する構造を示している．多くの場合，MD-MDA では，プラット考察

5

前節で示した 3 種類の MDA について，典型的なコンポーネントを例として，生成系の実現について考察する．

5.1

OD-MDA に基づく自動生成

フローズンスポット自動生成の典型的な例として，共通アーキテクチャの View Content 自動生成について述べる．View Content 生成のさいのプラットフォームはプログラミング言語であり，PIM はクラス図，PSM は当該プログラミング言語で記述されたクラス定義となる．プラットフォーム仕様は構造エディタで用いられた逆解析スキーマ (Unparsing Schema) を用いた具象構文情報付加の手法[1] を応用できる．多くの UML ツールではオブジェクトモデルアクセスのための API を持っている．オブジェク

フォームはそれぞれ独立であり，生成の順番は，それを問トモデルをたどるためのイテレータが用意されている場合わない．

が多いので，これを利用してオブジェクトの木をたどりな

RMDA は，PSM からプラットフォームを指定すること

がら逆解析スキーマを参照してフローズンスポットのソーにより PIM へのモデル変換を実現する逆モデル駆動アー

スプログラムを生成できる．さらに，PIM をクラス群の静キテクチャである (図 3 の赤枠)．前述のように，特定の設的構造と制御構造を定義したオブジェクトモデルとするこ

計や実装からアーキテクチャを復元するアーキテクチャ回とで，操作的意味のコード化が可能である．本稿では静的復と位置付けられる．

構造をクラス図，制御構造をコマンドパターンを用いたオブジェクトモデル，コマンドごとの操作的意味をアクティビティ図で記述することを想定している．

図 4 View Content の自動生成

図 6 Event Handler の自動生成

5.2

MD-MDA に基づく自動生成

MD-MDA を適用すべき例として，Display Image Constructor 自動生成について述べる．プラットフォームはビュー定義形式とプログラミング言語とし，MD-MDA を定義すれば生成可能となる．
プラットフォームがビュー定義形式のさいの，PIM は多層型のコマンドパターンを使って定義したオブジェクトモ
デル，PSM は特定ビューに変換するためのコマンドサブクラスを付加したオブジェクトモデルとなる．プログラミ
ング言語をプラットフォームとした場合の，PIM はビジ
ターパターン，イテレータパターン，およびコマンドパータンを適用したオブジェクトモデルとなる．PSM はこれらパターンの持つ操作的意味を当該言語に翻訳したプログラムとなる．自動生成の概要を図 5 に記した．

6

おわりに
本稿では，我々の提案する共通アーキテクチャの実現について考察した．共通アーキテクチャのすべてのコンポーネントについて自動生成の可能性について議論した．アー
キテクチャをアプリケーションフレームワークとして実現したさいに，すべてのフローズンスポットは自動生成可能であることが確認できた．ホットスポットについても，アプリケーションの仕様から自動生成または半自動生成可能なコンポーネントが存在することを確認した．共通アーキ
テクチャの目的である，“複数の開発環境と実行時環境の可能な任意組み合わせでアプリケーションが稼働すること”，に着目し，MDA に基づく自動生成について考察した．共通アーキテクチャのコンポーネントが OD-MDA，MD-MDA，または RMDA-MDA で生成可能であることを確認した．今後，これらのモデル駆動アーキテクチャに基づき，生成系を実現して行きたい．

参考文献[1] D. Notkin, Gandalf: Software development environments,” IEEE Trans. Soft. Eng. , vol.12, no. 12,
1986, pp. 1117-1127.
[2] Object
ManagementGroup,”http://www.omg.org/mda/, 2015.
図 5 Display Image Constructor の自動生成

5.3

RMDA-MDA に基づく自動生成

SAF コンポーネントである Event Handler の生成について述べる．RMDA のプラットフォームは状態遷移機械の記述形式，PIM は UML 状態機械図で表現した状態遷移機械，PSM は特定の使用者を想定した表現形式，例えば Excel で書かれた状態遷移表など，とする．MDA のプ
ラットフォームはプログラミング言語で，PIM は UML 状
態機械図で表現した状態遷移機械，PSM は当該プログラ
ミング言語で記述した状態遷移機械のプログラムコードとなる．自動生成の概要を図 6 に記した．

MDA,[3] S. Allen et al. , Pro Smartphone Cross-Platform
Development: IPhone, Blackberry, Windows Mobile and Android Development and Distribution, Appress, Berkely, CA, 2010.
[4] S. Lazetic et al. , A Generator of MVC-based Web
Applications, ” World of Comp. Sci. & Info. Tech.
J., Vol. 2, No. 4, 2012, pp. 147-156.
[5] 江坂篤侍，野呂昌満，沢田篤史， インタラクティブソ
フトウェアの共通アーキテクチャの提案， ソフトウェ
アエンジニアリングシンポジウム 2015 論文集，2015,

pp. 137-144.