HOME | イベント | ET2012 設計・検証ツールトラック UMLより10倍速い

UMLより10倍速い
=> ドメインスペシフィックモデリング言語

ドメインスペシフィックモデリング言語による テスト自動化、ソフト/ハードの協調設計環境、プラットフォームのコンフィギュレーション

 

スライド資料

 
 UMLやCなどの汎用言語に比較してDSM(ドメイン専用のモデル言語)による開発は、5~10倍の生産性になる。またDSM環境は小さくイテレーティブに進化させながら構築することで短期間に実践活用できる。本講演ではDSMによるコードの自動生成に加え、仮想HWの構築、テスト自動化、RTOSプラットフォームの構成など、様々な活用事例を紹介する
 

 

ドメインスペシフィックモデリングとは

 
 製品ファミリーに限定したモデリング言語とコード生成機能を、利用する組織自身で開発することで、そのドメインとニーズを正確に反映することができる。そのようなモデリング言語は、製品固有のモデル表記、用語、ルール、制約、概念など開発者に親しみ易く、極めて短期間で習得できる。また組織の要求だけを考慮するので追加や修正などの変更も容易である。
 
そして抽象度が向上し、独自のルールや制約を備えることで、システムを記述するための詳細化を要しないため、汎用言語(C、JAVAなど)による実装や、UMLモデリングに比較して、5~10倍の生産性が得られる。
 

 UMLモデルでは抽象度がコードレベルから上らないので、生産性への寄与は期待できない。

 

既に多くの成功事例(国内でもスローペースながら)

 
  大規模・複雑化する組込みシステムの派生開発・差分開発に特に有用であり、多くの成功事例が報告されるが、まだ手をこまねいている組織も多い。その理由として基盤となるソフトウェア資産が未整備であることが言及されるが、 高度なメタモデリングツール(DSM環境を作るための専用ツール)なら、小さく始めてイテレーティブに進化させられることが周知されず、敷居が高いと思い込む技術者や組織が意外に多い。
 
また、適さないツールや手法をベースにしたDSM環境は、開発やメンテナンスに多大な工数や費用を要することになることもあまり知られていない。

実はUMLのプロファイル機構によって特定のドメインやプラットフォーム向けにカスタマイズや制限できるが、これによるDSM環境の開発やメンテナンスには相当な労力と工数を要し実践的な解にならない。これの経験がコード生成の自動化に対する懐疑心を煽っていることを懸念している

 

良いツールなら構築期間も速い (DSM 環境の開発には数年・数億円かかると言われてきたが、、)

 
一般にはモデリング言語とコード生成機能を開発するには多くの時間と労力が掛かると認識されている。そして大抵の場合、数年もの工数が掛かるプロジェクトになると予想される。しかしながら我々の経験では全く異なり、ドメインによってはそれこそ数日でDSLとコード生成機能を実装できる。
 

更なる情報は画像クリックで

 

間違ったツールにより、甚大なリソースが言語やコード生成機能の開発とサポートに費やされることになる。OOPカンファレンスで聞いた悲惨な話で、Eclipse EMF を用いてモデル言語の構築に25人・年の工数が費やされたとの報告があった。そのような投資を出来る企業がそうそう有るとは思えない。ツールの違いに関して興味があるなら、OOPSLAのワークショップ(best practices for MDSD (Model-Driven Software Development))での以下の資料がお勧め
LinkIconこちらから(英文)

 
DSL、DSM 環境構築ツールに必要な機能は?
 
・モデリング環境、メタモデリング、コード生成機能が完全に融合され、既存ツールチェインと統合できること
・進化を支援できること。DSM言語の修正、拡張が容易で、既存アプリモデルが破壊されることなく
・マルチユーザ(異なるプラットフォーム、アクセス権限)
・標準ファイル形式によるインポート・エクスポート
・あらゆる言語、ドキュメントを自動生成できる仕組み
 

 

 

DSM言語の基盤について

 
・プラットフォームやフレームワークなどに代表される共通化開発がDSMの基盤となる
・共通化開発の課題は、製品間の変動要素(可変部)を上手く管理しないと破綻するということ
・DSMで変動要素(可変部)を管理する(可変部をモデル化してジェネレートさせる)
 

 既存システムをベースにして派生開発(差分開発)される製品であれば、製品ファミリーでコンポーネントを共有するフレームワークを構築して、それをドメインスペシフィックなモデルからアクセスさせることで、抽象度をあげて完全なコードやモデルを生成させることができる(再利用性の向上)。そのようなDSMなら独自のルールやコンストレインツを持たせて曖昧な要件・仕様モデルが描けないようにできる。

 

DSM用のプラットフォームの準備について

 
一般的にはプラットフォーム、あるいはフレームワークが上手く整備されている(バライアビリティ要素を踏まえた)のであれば直ぐDSMに活用できるし、最新版の製品から新しいプラットフォームをコピーしてくるのであれば多くの作業が必要。
ただ最新製品から新しいプラットフォームをコピーするところから始めるのが、経験上最も多い。コモナリティ、バライアビリティに上手にリファクタリングされていて、バライアビリティのみジェネレートできるようなプラットフォーム(フレームワーク)があるのが望ましいが、現実はそうではない。
 
それゆえ最初は既存のコードに合わせてジェネレータを定義する。そして、それをリファクタリングして定型部分や共通部分をサブジェネレータに取り込む。そしてドメインフレームワークへ、それらを取り込んでいくと良い。
 
DSM環境の構築(モデリング言語とコード生成機能の開発)を始める前にプラットフォームのリファクタリングをするくらいなら、上述の手段(動作するDSMを作ってからDSMを理解して改善・進化させる)ほうがずっと楽で簡単。
 

イテレーティブにDSMを進化させながら、プラットフォームも進化させればよい。プラットフォームも継続的に変更や追加などの進化をするので一度にやろうとしても上手く行くはずない。そしてイテレーティブにDSM言語を改善・進化させられるのが、他にはないMetaEdit+ の優位性。

 

なぜUMLでは駄目なのか? に、まだ興味があるなら 間違いだらけのツール選びへ