中間表現とフレームワークを用いた
Webアプリケーションの
メンテナンス法の提案と評価
明治大学 理工学研究科 早川 智一 長谷川 慎哉 吉賀 祥太 疋田 輝雄はじめに
本研究は，ITの現場で実際に起きている問題を
扱ったものです．
ご自身が担当SEになったつもりで（皆様ならばど
うするか考えながら）お聞き頂ければ幸いです．
今日のキーワード：工数
いきなりクイズ
～これで今日からあなたもSE～
工数とはなんでしょう？
以下の？はいくつでしょう？
1人日=？時間 1人月=？人日 1人月=？万円 以下のようなアプリの開発はどれくらい工数がか
かるでしょう？
四則演算のできる電卓（ただし，CUIで）システム開発は思いの外高い！
お伝えしたいこと
RIA（Rich Internet Application）は便利だが，互換性に
難がある．これは業務での利用時に特に問題となる． この問題の解決を試みた多くの研究やサービスがあるが， 決定的な解決策は未だ存在しない． 我々は「中間表現」と「フレームワーク」を用いる方法を 提案し，3種の実証例を作成して評価を行った． 各実証例は，まったく異なる3組のRIA技術に対して開発を 行い，それぞれに対して評価を行った． AjaxからOpenLaszlo，FlexからHTML5，中間表現からJavaFX 評価の結果は，我々の方法が前述の問題において工数削減 に有用であることを示した．
アジェンダ
1. 背景
2. 目的
3. 関連研究
4. デモ
5. 提案モデル
6. Web-IR
7. 中間表現
8. フレームワーク
9. 評価
10. おわりに
背景（1）
• インターネットの普及に伴い，Webアプリケーションも普
及．
• 近年では， RIA（Rich Internet Application）と呼ばれる
技術を用いたWebアプリケーションが台頭．
– 例）Google Maps，Gmail，Youtube，ニコニコ動画，Twitter， Facebook，Mixi，etc• 各社がRIAの実装技術をリリース．非常に多くの種類が
存在．
有名なWebサイトは，およそすべてが何らかのRIA
技術を用いて実装されていると言っても過言ではない．
ちょっと脱線
～我々のまわりのRIA技術～
ひとくちに「Webアプリケーション」と言っても， それを実装する技術はこんなにある． Ajax Flex （Adobe社） Silverlight （Microsoft社） HTML5 JavaFX （Oracle社） OpenLaszlo （Laszlo System社） 他にも多数 ブラウザのみで動作 実行時にプラグインが必要背景（2）
• しかし，RIA技術間には
互換性が無い
．
• これは，RIAを業務で使用する場合に問題に．
– 理由）選択したRIA技術が廃れると，他のRIA技術へ移植が 必要． • 業務アプリケーションはシステム規模が大きく移植コストが大．• そして，RIAの互換性の問題はしばしば起こる．
– 実例1）JavaFXは1.x系と2.x系で仕様が大きく変更され，後方 互換性が失われた． – 実例2）モバイル版のFlash Playerは新規開発が中止（2011年 11月9日発表）．背景（3）
• 一方で，RIA技術を1種類に集約することは難しい．
– 理由1）集約はハイリスク・ハイリターン． – 理由2）業務要件によって最適なRIA技術は異なる（一般的に はAjaxが好まれるが… … ）． • 例1）コールセンターでは応答性が重要．よって，高レスポンスな （≒Ajax以外の）RIA技術が好まれる． • 例2）勘定系業務では，画面部品の充実度が重要．よって，Flexや SilverlightなどのRIA技術が好まれる． 複数のRIA技術を使い分けなければならない現状を 踏まえつつ，それらの移植性を高める対策が必要．目的
• （特に業務アプリケーションにおいて）前述のRIA技術
の移植性の問題を解決する方法を提示する．
– 必要要件 • RIA技術の趨勢の変化に迅速に対応できること． • 業務要件ごとに柔軟な対応ができること． • あまり高級になりすぎないこと（利用者の使い勝手を考慮）． • 80:20の法則に従うこと． ※（ここでの）80：20の法則とは （1）全システムのうち80%に対応する（20%は特殊で無理） （2）1システムにつき80%の情報を移植できる（残りは手作業） （3）20%の工数で80%の仕様を満たす（残りはロングテール）目的（補足）
• 我々の目指すもの
– RIA技術の移植を容易にする方法論の提供
• 我々の目指さないもの
関連研究（1）～論文～
• 松塚貴英：業務アプリケーションに適用するAjax フレー
ムワーク，情報処理学会論文誌，2008.
– 業務アプリケーション用のAjaxフレームワークの提案． – 業務アプリケーションは大規模化しやすく，柔軟に構築する ための方法論が必要であると述べている． 類似点：効率的な業務アプリケーション用フレームワーク． 相違点：（1）対象となるRIA技術（Ajaxのみか・RIA技術全 般か）．（2）中間表現を用いないか・用いるか．（3）他関連研究（2）～商用サービス～
• Wallaby
– Adobe Systemsが提供する，Flash（FLAファイル）をHTML5に 変換するサービス．• Swiffy
– Googleが提供する，Flash（SWFファイル）をHTML5に変換す るサービス． これらのサービスの存在は，RIA技術間の変換に 一定以上の需要があることを示唆するものと考える．提案モデル
• 「中間表現」と「フレームワーク」を使用してWebアプリ
ケーションを汎用化する．
実証例が対応するRIA 1. Ajax 2. Flex 3. HTML5 4. OpenLaszlo 5. JavaFX 中間表現とフレーム ワークは特定のRIA技 術に依存しない．変換例
• 3種の実証例の変換例をご覧下さい．
1. JavaFXを用いた複雑な変換 2. Flexを用いたUI変換
変換例（1）～JavaFXによる複雑な変換～
• 対応RIA技術
– 入力：中間表現（Ajaxから変換） – 出力：JavaFX• 注目すべき点
– 複雑なCSSやJavaScriptを含むページを，外観をほぼ崩さな いで再現．• 力を入れた点
– 中間表現（XML）からJavaFX（Java言語）への変換．IE9によるWebページの表示（変換前）
JavaFXによるWebページの表示（変換後）
©Yahoo! Japan ブラウザではなく JavaFXになってい る． レイアウトはほとんど 崩れない（僅かに崩 れるのはスタイルポ リシーの違いによる もの）．デモ（2）～FlexのHTML5変換～
• 対応RIA技術
– 入力：Flex – 出力：HTML5（中間表現を経由）• 注目すべき点
– Flexで構成された画面を，表現力で劣るHTML5で再現（エミュ レーションライブラリを併用）．• 力を入れた点
– Flexには存在するがHTML5には存在しない画面部品を， HTML5とCSS3のみを用いて再現．HTML5（変換後・相対座標）
テキストエリアの大きさが 大きく異なっている（標準の スタイルポリシーの違い）．
HTML5（変換後・絶対座標）
絶対座標の場合は外観はほぼ同一． （実際のアプリケーションは，
デモ（3）～AjaxのFlash変換～
• 対応RIA技術
– 入力：Ajax – 出力：Flash（中間表現とOpenLaszloを経由）• 注目すべき点
– Ajaxの動的書き換えと非同期通信の機能を，大幅に仕様が 異なるFlashで再現（エミュレーションライブラリの併用）．• 力を入れた点
– AjaxのDOMやCSSの動的書き換え，非同期通信がFlashでも 動作するように再現．左：Ajax（変換前），右：Flash（変換後）
クリックする
（非同期通信と動的書き換えが 発生）
左：Ajax（変換前），右：Flash（変換後）
・非同期通信による画像の 取得
・DHTMLによる 動的書き換え
左：Ajax（変換前），右：Flash（変換後）
クリックする
左：Ajax（変換前），右：Flash（変換後）
Web-IR（1）～概要～
• Web-IRとは
– 中間表現とフレームワークからなるコアシステムと，それ を用いた実証例とを総称したもの．• 対応RIA技術
– 入力：Ajax・Flex – 出力：HTML5・JavaFX・OpenLaszlo ※入力のRIA技術は市場シェアなどを考慮して選定し， 出力のRIA技術はベンダロックインを避けて選定した．Web-IR（2）～コアシステムの特徴～
• 特徴
– 小さな基本部品を多く提供する • パーサ類（HTML，CSS，JavaScriptなど） – 基本部品を組み合わせて使用する• 諸元
– 計135個のクラスとインタフェース – 19,144行のJavaのコードで構成 多くのRIA技術の記述言語は似通っている．従って， 汎用的で小さな部品を用意しておき，必要に応じて 疎結合して使うのが効率的（例：パーサ）．中間表現（1）～概要～
• 既存のRIA技術の共通機能のみをもつ．
– メリット：多くのRIAに変換可能 – デメリット：表現能力が低下• 必要に応じて任意の要素を追加可能．
– 例）カレンダーなど – 追加時の追加工数は僅か（1人日以下）． 多くの業務アプリケーションにとってRIA 技術は手段に過ぎない．よって，中間表現に 必要なのは，機能性ではなく柔軟な拡張性． イメージ図中間表現（2）～概要～
• 内部は4部分に分割される．
– メタ情報 – ウィジェット情報 – スタイル情報 – 振舞い情報 情報をカテゴリごとに保存することで，部分的な再利用が可能 （例：振舞いは無視して画面情報だけ変換するなど）． ※RIAのクライアント側ロジックは基本的に入力チェックと画面 遷移のみ．ビジネスロジックはサーバ側．クライアント側の ロジックは十分小さく，手作業でもテストフェーズで吸収でき る．中間表現（3）～概観～
<?xml version="1.0" encoding="UTF-8"?> <application> <meta> <!-- メタ情報 --> </meta> <widget> <!-- ウィジェット情報 --> </widget> <style> <!-- スタイル情報 --> </style> <behavior> <!-- 振舞い情報 --> </behavior>• ファイル形式はXML
中間表現（4）～メタ情報～
中間表現（5）～ウィジェット情報～
• RIAのボタンやテキストボックスなどの画面部品に関す
る情報を格納．
– 多くのRIA技術が画面情報の記述にXMLを採用している． – 入力から中間表現へは情報無損失．
中間表現（6）～スタイル情報～
• RIAのフォントや文字サイズなどの，外見に関する情報
を格納．
• 記述形式はCSSをXML化したもの．
– 多くのRIA技術がスタイルの記述にCSSを用いる． – 入力から中間表現へは情報無損失． CSSの記述例 左のCSSをXML化したもの text { font-size: 10pt; } <rule> <selector>text</selector> <property> <name>font-size</name> <value>10pt</value> </property> </rule>中間表現（7）～振舞い情報～
• RIAのボタンのクリックなどのイベント情報を格納．
• 記述形式はECMAScript．
– 多くのRIA技術が振舞いの記述にECMAScriptを用いる． – XMLだと記述量が増えて可読性が低下する．• 入力の振舞い情報は，木と文字列データの形で中間
表現中に保存される（情報無損失）．
• 出力において，必要ならば変換する．変換が難しい場
合もある．エミュレーションライブラリの併用を推奨．
※エミュレーションライブラリを推奨する理由： （1）記述言語がECMAScriptであるRIA技術が大多数（文法は中間表現（8）～まとめ～
• 中間表現は
– RIA技術の最大公約数的機能をもつ． – 容易に拡張が可能である． – 内部で4分割される． – XMLで表現される． – 本質的には情報無損失である． ※注意点 「情報無損失」とは，入力側の情報が損失なく中間表現になる ことを意味するのであり，見た目や動作がまったく等価である ことを意味するわけではない（それは，出力時の処理に依存）．フレームワーク（1）～概要～
• フレームワークは，入力RIA・中間表現間と中間表現・
出力RIA間の変換を支援．
• 内部では全情報をDOM（Document Object Model）に似
た木構造で表現．
• SPIパターン（Service Provider Interface）に沿って設計．
– クラス名ではなく文字列を用いてインスタンスを生成． – 新しいRIA技術への対応や，既存の機能の拡張が容易．
• 学習が容易
– OOP
フレームワーク（2）
～重要なクラス・インタフェース～
クラス名・インタフェース名 説明 Application アプリケーションを表す ApplicationReader アプリケーションを読み取る汎用リーダを表す ApplicationWriter アプリケーションを書き込む汎用ライタを表す Translator アプリケーションを変換するための汎用 トランスレータを表す Visitor アプリケーションを変換する際のビジターを表す VisitorTranslator Visitorパターンを用いて実装したトランスレータフレームワーク（3）～概要クラス図～
クラスとインタフェースはSPIに基づいて設計．
フレームワーク（4）
～変換アルゴリズム～
特徴
Visitorパターンを用いる． メタ情報・ウィジェット情報・スタイル情報に関しては，XMLの木構造 を再帰的に変換する形で処理を行う． 振舞い情報は，抽象構文木（AST：Abstract Syntax Tree）を対象に
再帰的に処理を行う．
VisitorパターンはXMLと相性がいい．継承または委譲に
フレームワーク（5）
～疑似コードによる説明～
/** * Web-IRの変換を説明するための擬似コード． * この例では，入力と出力をそれぞれAjaxと * 中間表現と仮定している． * @param e0 変換されるHTMLの要素 * @return e0と等価な中間表現の要素 */Element visit(Element e0){ switch(e0){
case "<input type='checkbox'>":
Element e1 = new Element("<checkbox>"); while(e0.hasMoreChild()){
e1.appendChild(visit(e0.nextChild())); }
return e1;
case "<input type='text'>":
Element e1 = new Element("<textbox>"); return e1;
... }
評価テスト1～前提～
• 評価軸
– 各RIA技術と中間表現間で画面情報が相互にどの程度変換 できるか – 出現頻度による重みを考慮 • Web上のトラフィック上位10サイトからクローラを用いて算出．• 入力RIA技術
– Ajax・Flex（RIAのシェア双璧）• 出力RIA技術
– OpenLaszlo・HTML5・JavaFX Ajaxを処理できるということは，それ以外の既存のWeb アプリケーション（いわゆる「レガシーWebアプリ」）も評価テスト1
～トラフィックTOP10サイト～
ランク サイト名 URL 1 Google http://www.google.com/ 2 Facebook http://www.facebook.com/ 3 YouTube http://www.youtube.com/ 4 Yahoo! http://www.yahoo.com/ 5 Blogger.com http://www.blogspot.com/ 6 Baidu.com http://www.baidu.com/ 7 Wikipedia http://www.wikipedia.org/ 8 Windows Live http://www.live.com/9 Twitter http://www.twitter.com/ 10 QQ.COM http://www.qq.com/
評価テスト1
～集計結果（HTML・抜粋）～
ランク タグ 出現回数 出現率（%） （出現数/全出現数） 1 a 1,482 27.15 2 div 1,290 23.63 3 span 828 15.17 4 img 376 6.89 5 li 313 5.73 6 br 298 5.46 7 button 146 2.67 8 script 106 1.94 9 p 70 1.28 10 option 67 1.22評価テスト1
～集計結果（CSS・抜粋）～
ランク プロパティ 出現回数 出現率（%） （出現数/全出現数） 1 width 1,235 7.44 2 padding 919 5.53 3 height 902 5.43 4 display 902 5.43 5 color 842 5.07 6 background 692 4.17 7 margin 605 3.64 8 font-size 575 3.46 9 background-position 575 3.46 10 position 559 3.36評価テスト1
～ウィジェット情報の変換率～
入力 出力 変換率（%） 重みを考慮した 変換率（%） Ajax 中間表現 80.6 93.8 Flex 中間表現 44.0 N/A 中間表現 OpenLaszlo 100.0 100.0 中間表現 HTML5 90.0 N/A 中間表現 JavaFX 100.0 100.0 ・Ajaxに対しては，90%以上の変換が実現できる． ・Flexの変換率は低いのは，Flexのコンポーネント数が多いため である（中間表現の拡張機能を使えば，変換率は100%になる）．評価テスト1
～スタイル情報の変換率～
入力 出力 変換率（%） 重みを考慮した 変換率（%） Ajax 中間表現 100.0 100.0 Flex 中間表現 33.3 N/A 中間表現 OpenLaszlo 42.6 54.8 中間表現 HTML5 100.0 100.0 中間表現 JavaFX 62.3 95.8 ・Ajax・HTML5以外のスタイルの変換率が低いのは，CSSが 実際にはあまり用いられない多くのプロパティをもつためであり， 実用上は問題がない（ことが多い）．評価テスト2～前提～
• 評価軸
– RIAの画面開発による工数を比較．• 前提条件
– 被験者はRIAの初学者． – 外観が同じになるように作成．評価テスト2～結果～
単純な画面であっても，開発には多くの工数がかかる （スタイルポリシーや流儀の違い，不慣れが原因か）． RIA技術 学習コスト (人時） 開発コスト （人時） JavaFX 1.0 3.5 OpenLaszlo 1.0 9.5評価テスト3～前提～
• 評価軸
– Web-IRの使用の有無によるRIA変換システムの実装にかか る工数を比較．• 前提条件
– 3種類のRIAの変換システムの試作から評価を行った． – 変換対象は画面情報のみ（振舞いを含まない）．評価テスト3～結果～
入力 出力 Web-IRの 使用の有無 工数 （人時） 行数 Ajax OpenLaszlo × 10.0 1,450 Ajax OpenLaszlo ○ 5.0 960 Flex HTML5 × 24.0 1,818 Flex HTML5 ○ 18.0 1,231 Ajax JavaFX × 20.0 3,156 Ajax JavaFX ○ 12.0 1,627 Web-IRを用いると，RIAの変換システムを構築する際の工数と行数 が2/3から半分程度になる（設計方法論の強制によるものと推測）． ※数値のマジックに要注意：削減率がたったの1割でも，案件規模がおわりに
• RIAの移植性の問題を解決するために，XMLベースの
中間表現とJavaベースのフレームワークを使用するモ
デルを提案した．
• 上述のモデルを実装したWeb-IRを開発した．
• 3つの実証例を用いた評価は，我々のモデルが前述の
問題の工数削減に有用であることを示した．
• 振舞い情報の変換に関しては，機能を重要度ごとに分
別し，重要度の高いものから逐次対応を強化したい．
• （もっとさきの課題）システム全体の工数を削減するた
めには文字コードやSQLの標準化なども重要．
FAQ（1）
• Q1. 単なるトランスレータではダメなのか．
• A1. ダメな場合が多い．特にAjaxから他のRIAに変換す
る場合には，コンテキストに応じた変換が必要となるた
め難しい．
• Q2. 計算量はどれくらいか．
• A2. （実装依存だがVisitorパターンを用いるので）空間
計算量・時間計算量ともにO(n)である．
FAQ（2）
• Q3. レイアウトが崩れる問題はどう考えるか．
• A3. レイアウトを完全に一致させることは難しいため，
利用者側で微調整してもらうのが望ましい（ブラウザに
よっても異なるため完全な変換は困難）．
• Q4. スクリプトの自動変換はしないのか．
• A4. 自動変換に関して研究はしているが，可読性の問
題もあるため現在の手法が無難であると考える．
FAQ（3）
• Q5. 中間表現やフレームワークが廃れたらどうするの
か．
• A5. 中間表現はXMLなので他形式に容易に変換可能
である．フレームワークはJava固有の機能を使用して
いないので他言語に差し替えることは容易である．
参考文献（抜粋）
• Adobe Labs: Wallaby, Adobe Systems Inc. ,
<http://labs.adobe.com/technologies/wallaby/> • Google: Swiffy, Google,
<http://www.google.com/doubleclick/studio/swiffy/> • 松塚貴英：業務アプリケーションに適用するAjax フレームワーク， 情報処理学会論文誌， Vol.49, No.7, pp.2360–2371 (2008). • 三菱総合研究所：OSS デスクトップの普及に資するWeb コンテン ツ互換性向上に関する調査，情報処理推進機構オープンソフト ウェア・センター， <http://www.ipa.go.jp/software/open/ossc/seika.html>
