 |
|
|
Laurent Safa
松下電工㈱・EMIT ミドルウエア研究所
This paper was presented at The 7th OOPSLA Workshop on Domain-Specific Modeling in Montreal, Canada, on October 21st, 2007 (details here).
本資料では、ドメイン・スペシフィックなモデルからコードを自動生成させることにより、従来型 開発の5 倍の生産性向上を可能とする、ユーザインタフェース・デザインツールを開発した事例を 紹介する。はじめに、開発にいたる背景と、ドメイン・スペシフィック・モデリング手法(DSM)に取 り組んだ理由に関して紹介し、次に、仮想モデリング、および動的モデリングに重点を置いた、ド メイン・スペシフィックな記法に関して説明する。最後に、ツールの適用とメンテナンスに関して の考察で締めくくる。
今日のように、あらゆるものがデジタル化され、接続されるようになることで、ホームコントロー ラにおいても、エネルギー削減機能 [1]、侵入検知、地震警告など、より多くの機能が提供されてい る。これら新しい機能には、メニューをナビゲーションし、データを視覚化し、システムを設定で きる徹底したユーザインターフェイスが必要である。また製品システムは、複数のグループで開発 されたデバイスで構成されるため、統合されるものが増えるに従い、ソフトウエアの複雑さも増加 している。
弊社では、アプリケーションフレームワークを構築して、最適なコード実装と、選り抜きのコン ポーネントの再利用を実現することで、これら課題に対処することにした。ただ、ユーザインター フェイスに対する市場要求を調査しながらであったため、フレームワークそのものは、開発者の創 造性を阻害しないようにするため、意図的に制限することとした。
結果、フレームワークのプログラミングインターフェイスはドメイン・スペシフィックな設 定ファイルと、アプリケーションのスケルトン生成とし、追加のビジネスロジック、ビジュア ル・デザインは、プログラマーに残された。
アプリケーションフレームワークは、デバイス間の振舞いの不一致を抑止するのに効果的があるこ とが証明され、システムのインテグレーションが機械的にできるようになった。しかしながら、開 発者から、フレームワークを用いることに直接関連した、新しい問題が報告されることとなった。
フレームワークを用いて複数の製品を開発した後に、組み込みユーザインターフェイスの必要性を、 良く理解することができました。そしてまた、視覚的なモデリングツールを追加することで、フレ ームワークを拡張させることにしました。このツールにより、完全なコードを生成させて、体系的 にヒューマンエラーを削減させることを目指しました。
既存のユーザインターフェイスより、ページ内の視覚的デザインパターン（レイアウト、プロポー ション、タイプ、情報量など）、相互接続されるページのパターン、そしてアプリケーションソース コードそのものを、浮き彫りにすることができた。これら全てのパターンは、デザイングループに より定義された、ビジネス固有のガイドラインから起因している。
また同様に、要求仕様書からも社内独自の表記なども確認できた。この表記は、矢印、多様な幅 の線、ナビゲーションに関わる色、特別な振舞いを指定するアノテーションなど、ページの現実的 なスナップなるものであった。
最終的に、既存ユーザインターフェイスの 60%～80%が 5 つの最も多く使用されているページパタ ーンで定義されている事がわかった。
図1：パターンと要求のカバレッジ
調査の結果として、ドメインは視覚的なモデリングに有利であると判断し、ツール開発に取組むこ とにした。
既存の開発ガイドライン、パターンの用法は、ページの標準として、一定の形式を設けた。 例えば、メニューページは、飾りのアイコンからテキスト情報、ナビゲーションボタンなど 13 の部 品からなる標準パターンで形式化した。
図２：メニューページのパターン
他、反復するパターンとしては、配下の設備とのやりとりを含む、設定ページ。
図３：設定ページのパターン
「前へ」や、「次へ」ボタンを使ってメニューページ間を分割するような振舞いもまた、形式化し た。
図４：メニューの振舞いのパターン
ページの標準と、振舞いの標準を明確にできたことで、ビジュアルモデルから完全な製品生成を実 現する準備が整った。
少ないリスクによる新製品開発、既存の確立した手法などが優先される為、ツールの開発に割り当 てることのできるリソースは限られていた。このような状況に対処すべく、最小限のコーディング で安定したツールを構築できる、モデリングツールのためのツールキットを探すことにした。その、 選択基準は以下の通り：
MetaEdit+® で提供される、GOPPRR手法[2] と、MERL scripting language を結果として採用した。
GOPPRR と MERLによるツール構築に関しては、別の文献に詳細がある[3]。その為、この内容に関し てはスキップし、我々のツールに関する主要な部分に関して紹介する。
以下の図は、ユーザインタフェース・デザインツールの代表的な作業セッション
図５：ユーザインタフェース・デザインツール
視覚的なエディタに良くある、コンセプトや概念のブラウジング、アイコンバーなどに加え、 MetaEdit+® では、オンサイトでツールを構成できるようになっている。そのためメタモデルや、視 覚的な表記、ジェネレータなどの改修は、エンドユーザで開発に用いている真っ最中でも可能であ り、ユーザの提案を、その場で一緒に確認することが、面倒なプログラミング言語や時間の掛かる コンパイル無しに行える。簡潔・容易に変更できるということで、安心感を持ってモデリングツー ルを用いることの、相当な助けとなり得た。
サブモデルを包括できるように、視覚的なステートメントの記述を提供した。複雑さを上手く取り 扱い、音の設定や、ファームウエアのアップグレードなどの、スタンダードモデルの再利用を円滑 にすることが、その目的。これは、従来どおりの、要求セクションごとに、機能が関連するページ を分類する手法と、合っていた。各サブモデルは、一要求セクションに該当し、包括される各ステ ートメントは、要求仕様書の参照/再利用されるステートメントに相当している。
図６：モデルの包括
調査を進めていくうちに気付いたことは、規定されるユーザインターフェイスは、現実の製品ペー ジのスナップショットであること。モデルを最終製品に、できるだけ沿うようにすることは、製品 構築に関わる関係者が多様であることから、必須となっていた。この必要条件を遵守し、視覚的な シンボルは、製品ページのビジュアル・デザインを、そのまま模倣することにした。例えば、メニ ューページのシンボル（Fig.7）は、フォワードページ数、“前“ や ”次“ などのボタンにより、 分割されたメニューの連携有無、親ページの有無に従い変化する。
図７：仮想－実在的メニュー・シンボル
同様に、コンフィギュレーションページのシンボルは（Fig. 8）、選択肢数に応じてボタンのサイ ズが、忠実に変更される。
図８：仮想－実在的コンフィグレーション・シンボル
仮想－実在的シンボルは、最終製品のページに厳密な複製ではないが、ツールユーザにとって、貴 重な情報として用いられ、(Fig. 7)のようなメニューのシンボルをパッと見ることで、右が詰って いても、左端メニューに、追加のボタン領域があることが判るようになる。
シンボルは、モデル内のコンテクストを基に、動的に変更され、モデルは編集行為を即座に反映す る。Figure 9 は、２ページ間がリンクされる前と、された後のモデル。図の通り、右側のモデルで は、メニュー・シンボルに、追加のボタンが自動的に加わりコンフィグレーション・ページを呼び 出せるようになり、そのコンフィグレーション・ページには、追加の“戻る”ボタンが、自動的に 付加される。これらページ間のリンクを外すと、最初の状態（左）に戻るようになっている。
図９：動的シンボル
ツールの最初のリリースでは、５つの最も頻繁に用いられるページ (menu, configuration, question, confirmation, splash) をサポートし、モデル化し、60～80％に及ぶ代表的なアプリケ ーションが生成出来るようになった
様々なパターンに及ぶ、同等レベルのコードの複雑さを想定すると、これはソフトウエアデザイン、 実装、構成フェーズの生産性を3倍から5倍向上させたことになる。ドキュメンテーション、製品テ ストなど、より一層の効果が期待されるが、まだ十分には測定されてはいない。 DSM を手段として、極めて創造的な製品デザインに対して、改善の見込みは期待していなかったが、 当初の結果から、デザイン生成、デザインとコードの統合化も、同様に 3 倍から 5 倍の生産性向上 が得られた。
各ページの標準のビジュアル表記、コード生成機能、メタモデル環境実装などに、３人/日 を費や した。１ページ辺りの開発に 0.5人/日かかることを想定すると、その6倍、あるいはそれ以上でもメ タモデリングの価値があると考えられる。
反復して用いられるパターンに加えて、使用頻度の少ない、ツールで自動化するまでもない、多く のページが存在する。これらは“ようこそ”ページ(Fig. 10)や、製品固有のデータ表示ページなど である。
図１０：Low-frequency patterns happen to contain high-value element
この問題は、ツール供給と実践のギャップにも該当する[4]。この件に対処する為には、新しいタイ プのページに対する、セミ・コントロールな、自由なモデリングを提供する、エスケープ・セマン ティックが必要である。
図１１：メタモデル環境の遅延
未定義（ジョーカー）シンボルを用いて、エスケープ・セマンティックを提供した。目的は、モデ リング担当者が、ツールではまだサポートされていない、新たな製品機能を定義できるようにし、 それらをメニューやコンフィグレーションなどの現状サポートされているページのパターンに、統 合できることである。Fig. 12 では、シンプルな未定義（ジョーカー）のテンプレートを紹介して いる。（色により、ジョーカーを識別。赤は、メニューから。緑はコンフィグレーションから）
図１２：エスケープ・セマンティックのインスタンス
複数の標準エレメントが、しばしば頻度の少ないパターンに再利用されることが判った。タイトル (T), 前のボタン(P), 次のボタン (N), 戻るボタン (R), 関連ページへのリンク (S), 他のページからのリンク (O) など。これらは、セミコントロールなモデリングを用いて、モックアップページの生成を可能にし、十分な情報をもって開発作業中の製品に統合される。
自由なモデリングは、シンプルなテキスト(ST), 条件によるリンク (CL), 新しいページタイプの定義/提案 (PT)で、提供される。 この例では、モデリング担当者は、２つの区分で、特別なフォントページを定義している。最初の区分では、3 つのボタンが含まれ、ホームオペレーションモードがワンタッチで変更できるようになり、2 つ目の区分では、天気予報を表示する為の仕掛けを含んでいる。
要求に対するカバレッジと、使用頻度のいずれかを基準に、ユニークな新機能に対して開発リソー スを集中することなく、ツール化に際して、時間とコストに制限を設けた。このツール化の制限は、 任意に設けられ、ドメインに対する知識や、現状のマーケットニーズに対する認識に応じて、定期 的に再考された。
図１３：ツール化の制限
Fig. 14 は、5 つの標準ページ・パターン (menu, configuration, question, confirmation, and splash) と、エスケープセマンティックのための未定義（ジョーカー）シンボルでモデル化された、Home Control Panel [5] の１ユーザインターフェイスである。全 45 ページ中、27 ページが５つの標準ペ ージ・パターンでモデル化され、18 ページが未定義（ジョーカー）シンボルが必要であった。結果、 ユーザインターフェイス・デザインツールは、60％の要求仕様をカバーしていることになる。要求 を良く調べると、P1 と P2 の 2 つのパターンが明らかになり、これらをサポートすることで、7 ペ ージを追加サポートできる。これは、34/45 = 75% の要求仕様をカバーすることになる。
図１４：既存アプリケーションを５つのパターンと未定義（ジョーカー）シンボルでモデル化
技術的関心事に加え、廉価で進化させることができて、他者への技術移管が容易であるような、保 守可能なツールの開発を求めていた。 大学生を6ヶ月のインターンシップとして迎える機会を利用 し、いくつかの試みを実施した。彼のことを、フレッシュマンと呼ぶ。
社内で 1 週間が過ぎ、フレッシュマンはもちろん製品について、内在するフレームワーク、プログ ラミング・ガイドライン、モデリングツールなど、何も知り得なかった。しかしながら、ツールに 対する半日のトレーニングで、モデリングして、熟練者による実装コードと同じ品質の組み込みユ ーザインターフェイスを、わずかな時間で構築できるようになった。 そしてこの試みは、特定の アプリケーションドメイン、プロセスエリアに於いて、標準クラスの従業員に熟練者のパワーを与 える、我々のドメイン・スペシフィック・ツールの、能力の実証に役立つものであった。
フレッシュマンは、ツールとモデリング言語を理解できた。次に、我々のツールの順応性を評価す るため、彼に対して、全く異なるターゲットプラットフォームに対するコード生成機能の実装を依 頼した。
| Supported platform | Challenge platform |
|---|---|
| Embedded OS | No OS |
| CPU | microcontroller |
| MB RAM | KB RAM |
| QVGA screen | 101x64 pixel |
| color | monochrome |
| touch panel | 3-position knob (top, down, push) |
MetaEdit+® の、GOPPRR メタモデリング・アプローチと、MERL スクリプト言語を、標準の説 明書とサンプルのDSLを用いて3日で学習し、フレッシュマンは、ビルド/Flash書込み/実行、の自動 化まで含めたCコード生成機能を、追加の3日で実装することが出来た。
図１５：ツールを新たなターゲットプラットフォームへ適応
3ヶ月を過ごしたフレッシュマンは、適切にツールのコア開発に参与できた。このことは、安定し、 十分にドキュメント化された、GOPPRR と MERL の技術に対して、最小限のコーディングを選択 した成果であると確信する。
本資料では、従来型開発の 3～5 倍の生産性向上を可能とする、ホームオートメーション市場向け 日本語ユーザインターフェイスをモデル化し、生成する独自のユーザインタフェース・デザインツ ールを開発した事例を報告した。
そして、ツールの支持を円滑にするために重要な、いくつかの機能について紹介した：仮想－実在 的モデリング、動的モデリング、オンサイトに於いてのツールの構成。更に、ツールの制約の概念 と、エスケープ・セマンティックについて述べた。これらは、ツールにより提供される機能と、製 品開発の実践で必要となることの、ギャップに対処するうえで役に立つ。最後に、ツールの保守性 に対する課題に対して、フレッシュマンによる試みを実施し、調査した。このツールは、有効であ り、雇用現場に於いて、一般的なスキルの担当者でも保守可能であることを実証した。
全体を通して、本資料で報告したユーザインタフェース・デザインツールの開発は、社内に於ける マイルストーンとなった。製品品質のソフトウエアを生成し、ソフトウエアの構築作業をビジュア ルモデルからターゲットへ完全に自動化する。新たな製品開発への幕開けである。
図１６：First occurrence of complete synthesis and workflow automation for the embedded user-interfaces