ObjectSquare

[技術書籍紹介]


Executable UML

モデル駆動型アーキテクチャの基礎

Executable UML ステファン J. メラー/マーク J. バルサー著
二上貴夫/長瀬嘉秀 監訳
Executable UML研究会 訳
株式会社テクノロジックアート 編

翔泳社刊
ISBN4-7981-0602-X

オージス総研 オブジェクトテクノロジー・ソリューション部
黒田崇
Kuroda_Takashi@ogis-ri.co.jp



 本書の帯にはデカデカとこう書かれています。

「実装できないモデルは、単なるスケッチにすぎない」

 本書は、UML を用いて "実行可能な" モデルを作成するための、 1 つのアプローチを提供するものです。 ですから、スケッチのモデルでかまわないという方が購入しても 時間とお金と森林資源の無駄でしょう。

  • 副題について
  •  「MDA の基礎」という副題は多くの誤解を招くおそれがあるので、 中身の話に入る前に、ここで少し補足しておきます。 この副題を見ますと、MDA 自体のことが書かれてあると勘違いする方が多いでしょうが、 「MDA のことを勉強したければ、他の本を読め」と本書には書かれています。 では、「MDA の基礎」とはどうゆう意味なのでしょうか。 まずは MDA と非 MDA の違いを考えてみましょう。
     非 MDA 的開発プロセスは反復型とかそうでないものとか多々ありますが、 「分析モデル、設計モデル、実装へと落としていく中で、 詳細度、正確さを高めていく」という やり方が主流であるように思います。 この場合、分析モデルはクラス図だけであったり、 あるいは、クラス図+コラボレーション図だけで、 システムの厳密なロジック(詳細仕様)は設計モデルで作り込みます。
     一方、MDA では、分析モデル、設計モデルというあいまいな定義は用いず、 PIM (プラットフォーム非依存モデル)、PSM (プラットフォーム依存モデル)、 実装という区切り方を導入し、 PIM から PSM、あるいは PIM から実装へ "変換" するという表現を使用しています。
     ここで、PSM はちょっと置いといて、PIM から実装への変換を考えましょう。 手書きによる PIM → 実装変換 ならいくらでも逃げ道はありますが、 ツールによる自動変換の場合、PIM は、厳密で正確なロジックを含んだ、 実行可能なモデルである必要があります。  では、どうすれば正確で実行可能な PIM を構築できるのか? その問いに対する 1 つの答えが本書に書かれてあるということです。
     長々とお話ししてきましたが、 「実行可能な PIM ができなけりゃ MDA もくそもないよね」 ということを著者は言いたいんだと思います。
     つまり、  

    MDA の基礎(肝)== 実行可能な PIM(を構築する方法)
    ということでしょう。
     先ほどほったらかしにした PSM についてですが、 Executable UML では、実装 == PSM とみなしていますので、 PIM → PSM も PIM → 実装 も同じことだそうです。

それでは、本題に入ります。 ここでの切り口は本書の章立てとはまったく関係ありません。

  • まず基本

  •  Executable UML は実行可能な PIM を構築する術なので、 要件定義や実装、配置などの方法は提供していません。 (ユースケースについては少し触れられているが、 要件定義の 1 つの方法として使用しているにすぎない) Executable UML は UML のサブセット(プロファイル)という位置付けであり、 モデリングのツールとして、UML のクラス図、ステートチャート、 アクションセマンティックの 3 つを使用する。 もちろん、その他の UML ダイアグラムは使用するなということはなく、 PIM のある側面を表現するのに使用したり、 モデルの理解を促進するために補完的に使ったりします。 たとえるならレポジトリとビューの関係に近いでしょう。 レポジトリにはクラス図、ステートチャート、アクションセマンティックにより 定義されたモデルのセマンティックが存在し、 それらを UML ダイアグラムというビューを通して表現するという感じです。

  • Agile

  •  実行可能な PIM から実装へツール等による変換を行うことで、 比較的早期に検証を実施できるので、Agile な開発も可能です。 単なるお絵かきではないモデルを作成するというのは、 「無駄な成果物を作らない」という Agile の基本理念にもマッチすると思います。

  • Aspect

  •  Executable UML でいうところのドメインは、 MDSoC(関心事の多次元分離)のアスペクトに非常に近いものです。 (私には、同じことを言っているようにしか思えません) ある概念を複数の問題領域に分割し、 その問題領域(ドメイン)ごとに PIM を構築し、 実装時にはそれらすべてを 1 度にマージして統合するというのが、 Executable UML による開発の流れです。

  • 再利用性

  •  オブジェクト指向のメリットの1つに再利用性の高さがありますが、 Executable UML では、基本的に、再利用の単位をドメインとしています。 ドメイン自体はカプセル化されていますが、 ドメイン内はホワイトボックスでよいそうです。

読んでほしい人

 本書の対象読者レベルはインジケータによると中級〜上級となっていますが、 私はむしろ UML 初心者にお勧めしたいです。 もっと言うと、ソフト開発未経験者が一番いいかもしれません。 なぜかというと、Executable UML のベースになっている OO 手法は、 Shlear-Mellor 法というものでして、 正直、あまり主流派ではないんですよね。 ですから、他の手法に精通している方には、 どうしても受け入れがたいところがあると思います。 (頭の良い人なら、本書のエッセンスだけ理解して、 お得意の手法とマージすることができるかもしれませんが。)
 というわけで、頭が真っ白な方ほど、 飲み込みやすいということです。 クラスとか関連の抽出は多少癖がありますが、 お絵かきではない厳密なモデリングをするのに、 非常に参考になると思います。 ここなんかは、まさに初心者に読んでほしいところです。




■ 監訳者まえがき抜粋(東陽テクニカ 二上様)

 Executable UML とは、優れた OO(Object Oriented) 開発リーダーならば誰もが行っ ていることを明文化した上で高精度化したものだと私は思っている。 もちろん、細かい技術的な選択は異なるだろう。非同期のメッセージ通信は、採用し ないで従来型のタ スク分割と同期呼び出しを前提に OO をモデリングし実践するケースは多い。 しかし、こうした差異を別として基本を考えてみよう。まず、開発テーマをじっくり と考えた上で、 対象を適切な形で抽象化し、それに無理なくなじむソフトウェアアーキテクチャを考え る。これをもとに 、性能、経済性、実装条件を考慮しつつプログラムの試作を行って抽象的なイメージ から実行エンジン への変換を検証する。この筋道でよいことがわかったら、後は開発期間や予算、信頼 性要求を考慮して 一気に開発を進めるのは、できるリーダーの常勝パターンとも特徴とも言える。
 ただ、このリーダー主導の開発は、リーダーが病気にでもなろうものなら災厄に見 舞われる。拠り所 を失ったメンバーは、いたずらにコーディングに走ってみじめな結果に終わるのであ る。
 それに対して Executable UML は、UML の記法の基本やプログラミングを学んだ人間 が集まり、アジャイ ル(Agile)方法論的な開発を行えるクールな開発技術である。注目すべき点は、その モデリング構造の簡 潔さにある。小規模なシステムならばクラスと基本ステートチャート図があれば、き わめて正確かつ簡 潔にソフトウェアの構造と動作を記述できるのである。
 読者には、本書で示されたモデリング手法の醍醐味を堪能していただきたい。また 同時に、次世代の ソフトウェア開発方法として何を考えるべきかに少しの時間を割いていただければ幸 いである。


■ 参照




© 2003 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP