HOME | products | MetaEdit+ | ドメインスペシフィック モデリング セミナー2010

ドメインスペシフィックモデリング セミナー

70名以上の申込みを頂いて、午前・午後両方を合わせて相当な質疑応答が繰り広げられ、白熱したセミナーになりました。参加くださった方、ご質問で盛り上げてくださった皆様に感謝しています。

 

アーキテクチャ記述言語に活用される MetaEdit+ (午前の部)

  EAST-ADL、AUTOSAR、SysML など  スライド LinkIcon

 

派生開発/SPLE を支援する MetaEdit+ (午後の部)

  ドメインスペシフィック・モデリングと完全なコード自動生成  スライド LinkIcon

 

<質疑応答>

 
 <午前の部>
Q1:UML モデルもインポートできるか?
 
A1:可能。XML形式、XSLTの使用、パーシング(コードジェネレーターによりファイルからモデルを生成)など。またUMLのメタモデルは既にMetaEdit+でサポート済み。 モデルのインポートについて
 
Q2:ADLをサポートする上で、UMLエディタ と MetaEdit+ の違いは?
 
A2:アーキテクチャの観点から言うと、EAST-ADL、AADL、AUTOSARもUMLではない。UMLはアーキテクチャデザインに向いていない。 MetaEdit+はUML以外の言語が使え、UMLそのものも変えることが可能(既存のUMLの見栄えや生成されたコードに不満な場合はツールベンダーまかせとなるが、MetaEdit+ なら自分で変更できる) MetaEdit+を使う最大の利点は、コード生成がより良く行える点や、モデル言語内に明確なルール・コンストレインツを持たせることが柔軟にできること。
 
Q3:MetaEdit+ では、モデル変換とモデル統合の、どちらの事例が多いのか?
 
A3:ドメインとして統合するものが小さい場合、かつ複数の企業が関わる場合は、変換を採用する。例えば、自動車OEMメーカが機能の記述に関する部分を担当し、サプライヤーがそれをAUTOSARにマッピング、さらに別のサプライヤーという具合に企業間のつながりがあるが、OEMは詳細レベルまでは必要としなく、機能レベルで考え、サプライヤーレベルになると違った側面から考えるという必要性があるような場合は変換が使われる。 
一社だけの場合は統合を好む傾向にある。理由としては、自社で全て行え柔軟性が担保されるから。 2社以上の場合は、変換になることが多い。
 
モデル間統合の最新資料
 
Q4:親会社がEAST-ADL、ソフトベンダーが AUTOSAR を使っている場合、納品時にEAST-ADL への逆変換は可能か?  
 
A4:可能。現在 MetaEdit+ で進行中のプロジェクトがある。全てを包み隠さず見せたいのかどうか、ビジネス上の判断、あるいはOEM契約の内容に依存すると思われる。
 
Q5:ボートのデモ例のHWモデルと機能モデル間統合のルールについて
 
A5:各メタモデル間のコンポーネントの関連付けや、ルールなどはユーザーで指定可能。モデルの構成を変えた場合、そのルールチェックも変更させるように設定することも可能。
 
Q6:皆がメタモデリングに MetaEdit+を使いこなせるのか?
 
A6:全ての開発者がメタモデル(モデリング言語)を作るわけではない。再利用可能なコードや、フレームワークを作る開発者ばかりではないのと同じ。通常は、フレームワークの上にアプリケーションを多くの人で実装しているのと同じ。多くのユーザーはMetaEdit+を単にモデル化に使っており、メタモデルを作ることは無い。1人あるいは2~3名までの熟練者によりメタモデルが構築される。
 
Q7:既存ソースコードから、MetaEdit+を使うアプローチ?
 
A7:既存コードをコンポーネント(コード生成用)として扱うのか、あるいはそれらをモデル化するためのコンセプトを得るのが目的か。例えば C++やJavaのコードなら、MetaEdit+の機能で読み込ませて、モデルのコンセプトを得ることも出来る。
 
Q8: ボートのデモ 例 では1つの機能モデルに対して、複数のHWモデルを選択肢として定義しているが、どのHWモデルのパフォーマンスが良いかを解析するテクニックや事例はあるか?
 
A8:どのHWアーキテクチャを使うかという選択はコストに依存すると思われるが、何をもって十分とするのかがポイントですね。ユーザーが実際に行っているのは、サンプルHWアーキテクチャを作ってみて、コードを生成させて、TLAなど外部のツールで評価するということ。 ツールも適切なものを選ばれています。
 
また、 こちらのスライドの例 では、デザインモデル上に、それぞれの要件を付けている(フレームレートとか)。例えば、ディスプレイのフレームレートは25、アプリケーションのスループットは10fps以上などの性能要件。各エレメントに要件をアタッチすることが出来る。 そして生成したコードをテスト環境で実行させて、結果をモデルへ返すことができる。そして要件を満たせなかったものは赤色表示となる。モデル上で要件を満たしていることをジェネレーター側で計算させて確認することもできる。場合によっては、システムを実際に動作させてパフォーマンスを測ることも可能。この例では、パフォーマンスの判断を行うツールにデータを返すという方法になっている。  
 
 <午後の部>
Q1:ルールやコンストレインツ間の矛盾は自動的にわかるのか?
 
A1:コードジェネレータに判定の処理を持たせることができる。そして結果をモデル上に反映させるようなことも出来る。
 
Q2:メタモデルをアップデートした際に、前のモデルは使えなくなるはずだが、規模が大きくなった場合、全て作り直しが必要なのか?
 
A2:MetaEdit+ではそのような問題は無い。通常はメタモデルの更新に合わせて既存アプリモデルが自動更新される。これはモデリング言語を構築するためのツールとして、他の手法・ツールに無い大きな優位性。
 
 ただ最初にひどいメタモデルを作ってしまっていて、これを大幅に改善するという場合は、エレメントについては一部再利用が可能でも、まったく新しい言語を作った場合は、前のものは無くなってしまいます。当たり前のことですが、、
 
Q3:言語の違い(C, Javaなど)に応じたジェネレータがあるのか?GeneratorEditor にある定義をカスタマイズするのか? 
 
A3:無い。 ジェネレータ はモデルをASCIIでエクスポートするだけ。その仕組みを用いて、対象とするフレームワークに応じたジェネレータを定義する。そして、あらゆるプログラミング言語のコード、コンフィギュレーション、日本語などによるドキュメント、モデルなどを生成させることが出来る。
 
Q4:マルチタスク、マルチプロセスのソフトウエア開発で、モデルとGeneratorの設計上のガイドラインはあるのか?これらの同期をとらないといけない場合、モデルとGeneratorの設計の両方の考慮が必要なのか?
 
A4:Watchデモでは、複数のアプリケーションが並列動作している。例えば、ラップタイムの裏で通常の時計機能が動き続けている。ここで開発者はスレッドのことをまったく考えなくても済んでいる。(プラットフォーム側にリアルタイム性の考察を隠蔽)
 
 あるいはセマフォなどを考慮に入れたモデリング言語にすることもできる。並列処理やスレッドを扱える専用のモデリング言語。例えばAADLはスレッドやプロセスを扱うために開発された言語。他にも ErLang(エリクソンが作った)というマルチタスクを扱う言語もある。モデル化のコンセプトとしてはスーバーバイザとその下のワーカーの関係があり、スーパーバイザが一人のワーカーを開始させる、または全てのワーカーをグループとして開始させるというやり方がある。Dr.Joe Armstrong により開発されたモデリング言語。興味があれば論文を送ります。
 
Q5:モデリング言語に変更があった時、どのコードが変わったのかを開発者は知る必要はないと思うが、構成管理ツールに投入する際に、差分というものはDiffツールなどで開発者は確認する必要はないのか?
 
A5:Diffツールなどでコードチェックは可能であるが、お考えどおり通常コードの変化を見る必要はなく、むしろデザインの変化が重要。 モデルの2つのバージョンを比較するには、次のような方法がある。 詳しくは、こちらを参照
 
 *ドメインスペシフィックなDiffツールをジェネレータで定義する。モデルの何処が変わったかを生成させる。
 *あるいはモデルをXML形式でエクスポートして、外部のDiffツールでモデルの差分を検出させることもできる。
 
Q6:標準化されているモデリング言語を活用してDSMを構築したいと考えているが、UMLプロファイルであるMalteのサポートはどうか?
 
A6:MalteはUMLプロファイルであり、サポートしない。ユーザーでの定義付けは可能であるが、UMLやUML Malteは非常に規模が大きくて複雑。シンプルではなく、お勧めできない。
 
Q7:EAST-ADL、AADL、SYSML はどの程度サポート出来ているか?
 
A7:MetaEdit+ はモデリング言語を作るためのツールなので、これらADLの一部のみ採用される場合もあれば、独自の拡張を加えているケースもある。MetaCase社で受託して、モデル言語を作成することも行っています。MetaCase社は、EAST-ADL2 に関わる  MEANAD プロジェクトに参画 しています。
 
Q8:メタモデルを定義する際のシンボルの定義時に、アイコンを変える以外に、何か工夫などは可能か? 専用ダイアログBOXやマトリクスなどは効果的と考えるが?
 
A8:ダイアログのレイアウトや、見栄え、UI をカスタマイズ可能。また CodeGeneratorを使って、エラーがある場合は赤色で示すとか、ボタン名は大文字で始めるなどのルールを作ることもできる。他にも、デフォルトの値が入ってないといけないというルールの追加。 ダイアログのプロパティはテキストとは限らず、他のプログラムを呼び出したり、Edit可能なまたは固定のリストを使うとか、その時点での値設定も可能。あるいはExcelを呼び出して、そこから値を選択することも可能。 
 
Q9:メタモデルに与えたルール、コンストレインツに照らしてのモデルチェック以外に、形式手法など他のモデル検査ツールを使えるか? 
 
A9:可能。その目的のためにのみDSLを使われている例もある。Videoカメラの事例では TLA という解析ツールを使って、結果をMetaEdit+のモデル内に表示している。 またこの例では、要件が書かれており、テスト対象のモデルを評価し、要件を満たしていない場合は赤色表示される。 また、T-VEC TTMモデルの形式に変換し、モデル検査、テストベクタ生成をさせることもできる。
 
Q10: DSM構築に要した期間 は、どの時点からのものか?
 
A10:メタモデルの構築を始めた時点から。
 
 
-------------------------------------------------------------
 
 
 MetaCase社 Dr.Juha-Pekka氏が SWEST(組込みシステム技術に関するサマーワークショップ) での講演 に来日する機会にドメインスペシフィックモデリング (DSM)のセミナーを行います。既に多くの企業で実践活用されるDSM手法とそのノウハウをデモや事例を交えてご紹介します。ご多忙中とは存じますが、是非ご参加を賜りたく、下記の通りご案内申し上げます。

逐次通訳あり

 
◇2010年9月1日(水) (午前)10:00~12:00 と (午後)13:00~17:00 の2部構成
◇参加費無料 (事前登録制)
◇会場: 全国町村会館(永田町)
 
 
■お申し込み方法
 
(午前の部)、(午後の部)、(午前・午後両方)のいずれかの選択と、下記の内容をご記入の上 LinkIcon E-mail にてお申し込みください。

 お名前、会社名、部署名、住所、電話、E-mailアドレス

 
 
 
■午前の部 10:00~12:00(開場 9:30予定)(定員50)

  アーキテクチャ記述言語に活用される MetaEdit+

  EAST-ADL、AUTOSAR、SysML など
 
  組込みソフトウエア開発では、SWとHW 双方の異なるアーキテクチャの代替案を分析・管理する必要があり、様々なアーキテクチャ記述言語が求められる。 それら多くはインハウスで各企業あるいは特定製品専用に開発されている(Philips社のKoala など)。 また自動車ドメインのアーキテクチャ記述言語である AADLAUTOSAREAST-ADL など一定規模のコンソーシアムとして開発される DSL も多く存在する。それぞれ異なった目的を持ったドメイン・スペシフィック・モデリング言語として。
 
 このセミナーでは異なるADLのデモを介して実践的な使用法を紹介する。独自の形式(ルールやコンストレインツ)を持たせること、モデル間統合、コード生成、アーキテクチャ分析機能など拡張が容易な MetaEdit+ により、組織に合わせた柔軟な取組みが行える。また組み込み機器開発では異なる技術者間の協調作業が求められることを念頭に、HW/SWのコデザイン、EAST-ADL と AUTOSAR といったADLの統合などについて紹介する。
 
 
■午後の部 13:00~17:00(開場 12:30予定)(定員80)

  派生開発/SPLE を支援する MetaEdit+

  ドメインスペシフィック・モデリングと完全なコード自動生成
 
 生産性向上と品質改善が得られる ドメインスペシフィック・モデリングとコード自動生成についてのご紹介。成功への手掛かりは抽象度を上げること。
 
 ドメイン・スペシフィック言語やモデル駆動開発は誇大に宣伝され・散発的な成功に限られてきたが、だんだんと広範に実践活用されるようになってきた。それは抽象度のレベルを上げることで生産性を向上させ、品質を改善するといった成果を伴って。そこで課題は、何処に対してどのように活用するかということ(もはや何故?・何を?といった議論ではなく)
 
 このセッションでは、”ドメイン・スペシフィック モデリングとコード生成” の最適な適応領域(その逆も)と、ソフトウエア開発効率を向上させるための活用法について紹介する。UML のような、どちらかというとコー ドレベルにフォーカスされるモデリング言語と DSM との違いにも言及する。これらは様々な組込みSW開発現場のDSMの実践的な活用例を引き合いにする。そしてセッションの中心は DSM の実装・構築について(どこに活用すべきかの選択、ドメインコンセプトの識別・それらのメタモデルへの形式化、様々なコード生成環境の構築、レガシーコード(ハンドコーディング)とコード生成機能の統合 など)。
 
 -DSM について
 -UML のようなコードレベルのモデリング言語との違い
 -様々な産業界に於ける実績紹介、デモ
 -ドメインスペシフィックモデリング言語に最適な領域は
 -ドメインコンセプトの特定法とメタモデル化
 -コードジェネレータの仕組み
 -レガシーコード、ハンドコード と自動生成コードの統合
 -デモ:メタモデルとコード生成機能が簡単に出来ることの紹介
 -MetaEdit+ の優位性 ”成功を支える重要なツールの機能”
 -Q&A セッション
 

講師紹介

Dr.Juha-Pekka Tolvanen 氏は、1991年からモデル駆動開発、メタモデリング、DSM言語に取組み、貢献をしている。ワールドワイドで多岐にわたる企業へのコンサルタントを通じて多くの論文を発表。OOPSLA では2001年から DSMワーク ショップ を運営し、今年10周年を迎える。また DSM Forum を立ち上げて、モデル駆動開発の主導的役割を担っている。 Juha-Pekka氏がCEOを務める MetaCase社 からは、IEEE Software特集記事 ”ドメインスペシフィックモデリングのワーストプラクティス” が掲載された。  DSM に関するブログ 

 


2007年 セミナー ドメインスペシフィックモデリング導入のコツと事例紹介

 MetaCase社 Dr.Juha-Pekka氏 がソフトウェアプロダクトライン国際会議 (SPLC 2007)での講演に来日する機会にセミナーを行いました。お陰さまで予想以上に多くの質問を頂戴しソフトウエアの再利用やモデル駆動に関する皆様の興味の深さを改めて認識する機会になりました。当日の資料をダウンロードしていただけるようにしていますので、ご参考頂けると幸いです。セミナー資料 日本語版 2種(8.5MB) LinkIcon