********************************************************************** セッションS5-a テーマ：「DSL」タイトル：「DSMによるユーザインターフェイスデザインツールの開発」講師：Laurent Safe(松下電工) コーディネータ：佐藤洋介（デンソー）日時：2008/9/5 15:10〜16:50 ********************************************************************** コーディネータ「それでは時間になりましたので始めたいと思います「DSMによるユーザインターフェイスデザインツールの開発」ということで松下電工様のLaurent Safeさんからご講演頂きたいと思います。」 Safe氏「みなさんこんにちわ、今日はモデリングツールユーザとして集めた経験と結論を皆さんと共有したいと思います」「ドメインスペシフィックモデリング(以下,DSM)という言葉は聞いたことがありますか？さっき聞いた？」「ではこれから発表したいと思います。もう少しで週末になりますから、もうちょっとがんばってください」１：松下電工（以下番号は、スライドの章と対応）私たちはホームオートメーション（住宅制御システム）やビルオートメーション（ビル制御システム）を作る研究をおこなっています。私はその中の先行技術研究所で働いています。そこでは技術のための技術とプロセスと商品を作っています。数年前から住宅制御システムを発売し始めました。ライフィニティというシステムです。住宅にある設備機器をネットワークでコントロールするシステムです。照明制御・エアコン・セキュリティ・防犯・防災などを制御することができます。このようなたくさんの機能を提供した時の問題点としてUIの問題があります。・どうやってユーザの多くの機能を提供するか・どうやってユーザは制御を行うのか・どうやって情報を見せるのかこの問題に対し、私たちはコントロールパネルというものを使うことにしました。コントロールパネルは小さい画面にタッチパネルの機能がついたもので、 PCほど大きいものではなく組込みシステムです。これから説明するのは、このシステムのUIを開発するためのツールを作った内容についてです。このツールはモデリングベース、ドメインスペシフィックモデリング(DSM)です。２：必要性どうしてこのようなツールが必要となったのでしょう？数十年前までは、洗濯機・テレビなどひとつの機器を制御するだけのソフトウェアだったので、一人でも十分に開発が行えていました。しかし、現在の組込みシステムは音声・動画・メモリ管理・セキュリティ・携帯電話との接続など多くの機能を必要とし、またそのそれぞれの機能ごとにいろいろ実装の方法があります。それによって作成するソフトウェアは大変複雑になってきました。ソフトウェア開発費用は、適用する機能の難しさに対して指数的に増えます。ソフトウェア開発者は20年前と変わらず、多くはテキストファイルでソースコードを書いています。しかし解決すべき問題は全然違ってきています。システムがこれほど複雑になってくると、ソフトウェア開発費も膨大となります。今までにも、CMMによるプロセス改善、AutoSarのようなフレームワーク、標準化プラットフォーム、再利用コンポーネント、オブジェクト指向など多くの改善を行ってきました。これだけの改善を行ってきているが、ソフトウェアの複雑さはこれらの解決策より早くより複雑になってしまいます。違う軸の改善を行う必要があります。自動生成と作業工程の自動化が必要となります。これは30-40年前に工場にロボットを設置したのと同じような変化です。工程を自動化するのです。連続して同じような作業をするのは人間は下手です。このようなものはロボットにやらせるべきです。これをプログラム自動生成と作業工程の自動化と呼んでいます。 DSMの宣伝では、DSMをあなたの会社で使えば生産性は５倍・１０倍よくなる、という話があります。これはいろんなところで明確にされています。こんなにいいものなら皆さん使うはずです。しかし使っていないのには理由があります。見たことがない問題・新しい問題を解決することは人間にしかできません。一番目のアプリケーションを作ってもらいます。これも人間にしかできません。しかし、今後同じような商品を作る、例えば、日本で作ったものをヨーロッパに持って行き、フランス・イギリス・ドイツにするには、ちょっとだけ違うソフトウェアになります。このような場合、DSMを使うことができます。 DSMは10倍生産性を向上することができますが、ドメインスペシフィックモデリングのスペシフィックという言葉があります、これはある事業ドメインを目指してツールを作ること、つまり特定のドメインを指します。すべての技術に対して使うわけではなく、今回はアプリケーション層を対象として使っています。組込みシステム全体のコストで見たとき、アプリケーションは全体の1/6くらいです。 DSMを使えば1/6はほぼ0にできます。これは全体的に見ると14%のコストダウンになります。 1億のものは8500万くらいになります。生産性が10倍向上するのは一部分だけですが、でもそれだけでも結構おいしいです。 DSMで作成したツールは私の会社でしか使いません。自分のドメインのために使います。ソフトウェアの需要は変わっていきます。ずっと連続するツールの更新・メンテナンスにも用いることができます。３：ソフト開発の分析開発を効率化するツールを作るためには、ツールを開発をする必要があります。そのために開発チームを回してもらうのは・・難しいです。このためMetaCaseを選択しました。MetaCaseのMetaEditはツールのツールキットです。半分完成しているツールで、ツールを作るための環境です。ツールを作っているというより、ニーズに合わせてカスタマイズする感じです。これはツールを作るよりも早いです。事業はずっと移り変わっていくので、当初効率化できると思って作っていたツールが数年後完成した時には、事業の内容が変わってしまってしまっているかもしれません。できることならツールは数週間内で作りたいものです。４：ツールの目標ツールの目的は、・製品品質の確保・生産性向上（開発時間の短縮、コスト削減）です。話す相手に合わせて話す内容を変えています。・製品品質の確保マネージャ・生産性向上開発者、グループリーダー・コスト削減マネージャそして、徐々に会社にエデュケーションさせます。 DSM,DSLは新しい技術なのでまだ慣れていません。あなたの会社にうまく活用したかったら、推進の活動を行う必要があります。現在のメインはツールの開発よりは、推進です。毎月なんらかのイベントを行ってみたり、ピザモデリングといった、ピザを買って人を集めてモデリングしてみたりする、といった慣れてもらうための何かしらの活動が必要です。５：ツール開発のデザインプリンシプルツールはソフトなので、アプリケーションソフトと同じように作る前にデザインプリンシプルを決める必要があります。どんな柱を元に作っていくか決め、その柱を守って作っていきます。守らないで作っていくと徐々に変なソフトウェアになってしまいます。私たちには２つの柱があります。・In-house notations 松下専用のノーテーションしか使わない。違う表記法が入り混じってしまうと疎通が図れません。ノーテーションの統一が必要です。 UMLはとてもいいけど、新しいノーテーション(UML記法)に合わせる必要があります。現在すでに何かしらのノーテーションがあるのに、新しいものを取り入れるのは難しいです。 UMLでは会社をツール(言語)に合わす必要があります。一方DSMはツールを会社に合わすことができます。・Model is the source モデルはソースで使えるために作る。 UMLではまだすべて書ききれていません。クラス図を描いてもまだコードができるわけではありません。もう少し上のレイヤでモデルを記述するとソース生成に必要な情報が入っています。６：ツール導入従来の開発方法は直接アプリケーションを書きます。数年かけて開発し数億円のものを作ります。そして組込みソフトウェア開発者は直接コードをいじります。これは開発者はあまり意識していませんが数億円のものを直接触っていることになります。一行いじったためにバグが入る可能性があります。 DSMでは直接コードを書きません。 Modelに触れるだけで、あとツールを使ってのみコードを生成します。ツールによって事前にHumanFactorのエラーを防ぐことができます。コードには手が入りません。開発者に考えてもらうのは、新しいこと"どんなアプリケーションや製品作りたいか、機能を適用したいか" これを考えてもらいたい。中のコードや設定ファイルは生成されます。 DSMを適用するためには、フレームワークがしっかりしていないと難しいです。再利用しやすい構造があり、使いやすい環境が用意されていることが必要です。コメント「自動生成後のコードに対してQAが検査していますが、自動生成されたコードの可読性は実用に耐えうるものですか？」ツールを作る前にフレームワークを作ってもらっており、そのコードは各専門者が作ったもので、ツールはそれと同じようなコードを生成するように作るので、可読性は高いものが生成されます。組込みソフトウェアは難しくコードを読む必要があることもあるので。コメント「設計意図はどのように扱っていますか？」実装ではなく、機能仕様（要求仕様）のレベルでモデリングするので、このレベルだとインテンション（意図）が分かります。UML等は開発者しか読めませんが、要求仕様ならステークホルダーが理解することができます。７：ツール開発手法コントロールパネルのUIを作るツールを作るのに、既存製品を分析しました。既存のUIを調べPatternを探しました。複数のUIを見るとやはりパターンがありました。 "戻る"・"次へ"は下の方にボタンがあることが多く、メニューは真ん中の方でした。さっき見せたコントロールパネルの例では、およそ20のパターンがありました。そのうちの５つのパターンが全体の60%を占めていました。５つのパターンを用意すれば、６割のものを自動生成することができます。当然対応できるパターンを増やすことはツールを作るコストが高くなります。どこまでDSMで扱うかはケースバイケースです。１つ２つだけのユニークな製品開発では、オートーメーションはあまり嬉しくありません。３番目の製品あたりから有益になってきます。 DSMを開発するときには、同じような製品がいくつあるかを考えてください。繰り返し同じような開発を行うようなドメインで有用です。導入を希望してくるメーカには２つの質問をしています。「同じような製品を連続して作る計画はありますか？」これが無いようならバイバイ。お話にならない。「パターンが固まっているか、ちゃんとやっていることがわかっている人がいますか？仕様は固まっていますか？」これもダメだとバイバイ。両方OKで初めてDSMを適用することができます。うまくDSMを適用できるところと使わない方がいいところをうまく切り分けることが必要です。８：UIデザインツールのデモいっぱい話をしたので少しは信じてくれたかな？ここら辺で少しデモをしてみようと思います。・仮想モデリングモデルの中に機能を表現します。その表現はリアリスティックで、製品に近いイメージでモデリングできます。 UMLのモデリングは仮想じゃありません、UMLでいくら書いてもどんな製品になるかは見えません。・動的モデリングモデリング言語は動的に変わります。シンボルも。これはデモをした方がよく分かります。 ----- コントロールパネルのページ遷移のモデルが表示される ------ DSMは複雑である必要はありません。KISS(Keep It's Simple Solution)。青いページは設定のページ、緑のページは入力や情報ページです。デザインやユーザビリティの専門家が居れば、ページのデザインや操作性（ページの深さなど）をこの段階で検討できる。コメント「メニューを変更すると自動的にメニュー画面にメニューが追加されるのですか？」遷移先を変更すると、自動的にその遷移先へのボタンが追加されます。 ----- あるメニュー画面からの遷移を別のメニュー画面への遷移に変更、それに伴いメニューのボタンが自動的に更新された ----- コメント「今、メニュー画面には４つくらいしかメニューが入らなくなっていますが、４つ以上入れるとどうなりますか？」モデリングに対していくつかのルールが設定されており、ルールから外れる場合警告が行われます。 ----- ５つ目のメニューを追加しようとすると、"４つ以上追加できない"という旨のダイアログが表示された ----- ・実行ファイル生成 ----- PC上でシミュレーション先ほどモデリングした画面遷移をブラウザ上で表示・操作できる ----- もちろんコード生成できます。C, HTML, CGIなど。各言語の詳細を知らなくても使うことができます。・モデリック・デバッグ -----先ほどのシミュレーションを操作すると、モデル上で遷移が表示される ----- 生成コードと連携して、現在の操作や状態を開発ツールに送ることができます。・再ターゲッティング今回見せたデモでは一切実装を見せていません。モデルの中にプラットフォーム依存の情報を埋め込むと、そのモデルを他のプラットフォームに移行できなくなります。しかし、内部ではちゃんと切り分けされているので、プラットフォーム独立部は容易に再利用できます。 ----- ビデオで先ほどのUIを別のマイコン上(別プラットフォーム上)で動作している所を再生 ----- まったく同じモデルを使って、他のプラットフォームで動かした例です。 OSが無いようなマイコンの上でも動作させました。コードジェネレーションは、ほぼ誰でも触ることができます。難しいコードを触る必要はありませんまたDSMを作ることで、再利用性が格段に上がります。９：デモのまとめ DSMによる新しいプラクティスが発生することにより、それをマスターする必要があります。新しいスキームと新しい人材が必要です。エキスパートから抜き出したツールはエキスパートと同様のことができるようになる。ツール開発者はエキスパートから技術を聞きだしてツールにする。エキスパートは新しい仕事をすることができ、ツールを使うことで一般の人でもエキスパートと同様の開発が行えます。１０：発表のまとめ DSMを行ったときに、UMLと比較するとモデルの中により多くの情報が含まれています。今回使ったモデルをUMLで描くともっと多くの図が必要になっていたでしょう。 DSMは必要な情報だけモデリングすることができます。コメント「一番最初に導入した際にかかった工数や、参考にした文献等があれば」 MSやその他いろいろやっています。MetaEditでもやっているのでデモの例は多くあります。最初に独自の言語を作るまでにやはり少し掛かります。コメント「旧資産の流用は可能？」ソースコードなどは、フレームワークの中などに再利用できます。他のツールでは、フレームワークやライブラリを導入する必要がありますが、 DSMは今まで使ってた手法に合わせて使うことが出来ます。（ツールにプロジェクトを合わせるか、プロジェクトにツールを合わせるか）補足「言語を作ることとフレームワークの設計は表裏一体。MetaEditで生成を行う場合、ライブラリを呼び出すの形にするのが一番シンプルです」コメント「モデルとメタモデルの乖離の問題やメタモデルの扱いはどうなりますか？」今日はメタモデルの話はしていないが、メタモデルとモデルはすべてひとつのDBに含まれており、一緒にバージョン番号を付与されています。どうやってバックワードコンパティビリティを防ぐかは面白い問題です。