07

13

モデル駆動開発(MDD)の現状と課題

2010.07.13(20:26)

翔泳社さん主催で、2010 年 7 月 8 日 (木) に開かれた、
組込みソフトウェアモデリングフォーラム2010
http://codezine.jp/event/uml/2010/
のパネルディスカッションに参加してきました。

その中で、モデル駆動開発(MDD)の現状と課題について、PPT資料3枚使って説明しました。



MDDの現状では、モデル駆動開発ツールの例としてRhapsodyでどのようにしてモデルを定義し、モデルからソースコードを生成しているのかの動画デモをやったあと、現状としてどこまでできるようになっているのか、その課題はなんなのか、について説明しました。

モデルからC/C++のソースコードを100%自動生成してくれます。どうしてそれができるかというと、クラス図と状態マシン図に自分が書いたソースを埋め込んでいるからです。モデルから作り出されたコードに自分が書いたソースが組み合わさって、ソースコード全体が出てくるようになっています。

シーケンス図は、オブジェクト間のインタラクションを記録した図面です。動作確認に使います。人間がシーケンス図を描くものではありません。

モデルを動かして検証することがPC上でできます。そのとき、リアルタイムOSの動きもPC上でシミュレーションします。なので、タスク、セマフォ、ミューテックス、イベントキューもPC上でシミュレーションします。抽象インターフェースを使って動くマルチタスクアプリを書く書き方自身がプロダクトラインを実現するヒントになっています。

さらに、MDDツールはいま、プロダクトラインサポートに注力しています。1つのモデルから製品群を作り出すことがスムーズにできるように改良を続けています。



次に、MDDのいいところについて話ししました。

必然的にモデルに描ける設計にせざるを得ません。ずるができません。制約にしたがって設計することになるので、一定の品質になることが期待できます。

モデルからソースコードが出てくるので、コーディング規則の細かいところを議論する必要がなくなりました。人間がやるのはクラス名やメソッド名、変数名にわかりやすい名前をつけること、くらいです。

ソースコードはモデルに埋め込まれているので、モデルさえ構成管理しておけば、ソースコードは構成管理する必要がありません。

初期オブジェクトから関連線がつながっているクラスのソースコードだけが生成され、そのソースだけがMakefileに追加されるので、それをうまく使うとプロダクトラインをコントロールすることができます。

一番便利だと思うのが、クラスブラウザ、関連ブラウザとして使う時です。クラス図でクラスをクリックすればすばやくそのソースにアクセスできます。関連を追跡するのも容易です。あるクラスを変更するとその副作用がどこまで及ぶのか簡単にわかります。

パッケージを名前空間に割り当てたり、パッケージに入っているクラスを特定のディレクトリに生成させたり、全自動でできます。リファクタリングも1ヶ所でやれば全体に渡る変更も簡単にできます。

複数のUML図面からソースコードを生成できるので、たとえば、分析クラス図と設計クラス図の両方の見方をすることも簡単です。両方から矛盾のない単一のソースコードが出せます。

MDDは製品コードだけじゃなくて、テストスイートを作るのにも大活躍です。



ツールを初めて使うときにコツが少々あるので、C++やオブジェクト指向なども初めてだとかなり難しいです。C++やオブジェクト指向やいいモデルを作れるスキルがあって、安定した小規模パッケージをそのままMDDにするところから、ツールの壁を越えましょう。

MDDはツールです。ツールいれたからといって、いい設計になったりしません。よいモデルを作ることやよいモデルを維持するスキルはツールとまったく別に調達してください。ごみをいれるとごみしかでてきません。

最初に導入したときはもちろん製品の大部分はレガシーコードで、MDDで作り替えたところはごく一部です。なので旧資産との境界をうまくつなぎあわせるところがちょっとたいへんです。旧資産をまたがった、可変点管理、自動生成管理も必要です。昔のMakefileと、MDDツールが作ったMakefilとの折り合いも必要です。できれば凝集度が高く結合度が低いパッケージにしてからMDDに移行することをおすすめします。

構成管理ツールが、モデルをパッケージ単位で構成管理するか、クラス単位で構成管理するかも考える必要があります。プロダクトライン戦略が決まっていればスムーズですが、それも悩みます。

単純な状態マシンだとあまり困らないと思いますが、複雑な状態マシンを派生機種展開しようとすると、静的構造をデザインパターンで解決したようにはうまくいかないことに気がつくと思います。状態マシンは1つのクラスの内側にあるので、その1つのクラスの中で「デザインパターン」しなければなりません。そこで #ifdef をたくさんいれてしまっては元の黙阿弥です。

いろいろ書いてきましたが、むずかしいところ、と思っているところは、実はそれほどは困っていなくて、MDDツール的には十分満足しています。ほんとうにむずかしいところは設計者の設計スキルと、設計者間コミュニケーションや開発プロセスなどです。それらは、新しい技術をいれようとすればいつでも起きる問題ですね。それさえ乗り越えれば10倍~30倍の生産性向上も夢ではありません。

コメントの投稿

非公開コメント

プロフィール

島敏博

Shima Toshihiro 島敏博
信州アルプスハイランド在住。HaskellとElixirが好き。組み込みソフトウェアアーキテクト、C++プログラマ、山歩き、美術館巡り、和食食べ歩き、日本赤十字社救急法指導員、インデックス投資、クラシック音楽、SESSAME会員、状態マシン設計、モデル駆動開発、ソフトウェアプロダクトライン、Rubyist、実践ビジネス英語

■ ツイッター
http://twitter.com/saltheads
■ Facebook
http://www.facebook.com/saltheads
■ Qiita
http://qiita.com/saltheads

印刷する場合は、ブラウザの印刷メニューではなく、このページの上から3cmくらいの青いところにある、「印刷」を押してみてください。少しうまく印刷できます。まだ完全ではないのですが、これで勘弁してください。


カテゴリ
最新記事
月別アーカイブ
最新コメント
検索フォーム
リンク
sessame
RSSリンクの表示