［レポート］
| (株)オージス総研 水野正隆 |
今年で 4 回目となる UML フォーラムが、2004年4月13, 14日の 2 日間、青山テピア(東京/青山)で開催されました。UML 2.0 の正式発表を間近に控え、MDA 対応と謳われたツールが市場に現われ始めた今、OMG やツールベンダ、UML/MDA を推進する企業は、どのようなメッセージをこのフォーラムで出すのでしょうか。ここに、広場編集委員が聴講したセッションの内容やフォーラムの雰囲気を、所感を含めて記したいと思います。
今年の UML フォーラムの特徴を 2 つ挙げることができます。１つ目はビジネスモデリングのトラックが設けられたこと。２つ目は、「MDA はコードの自動生成の技術ではない」と多くの講演者が話されていたことです。
前者は、モデリングの対象が、システム化したいターゲットから企業の業務そのものに移ろうとしているこの時期において、ドメインモデルからソースコードまでをカバーするモノづくりの可能性が MDA にはあるからではないでしょうか。後者に関しては、これまでの MDA への意識がモデルからコードの自動生成に集中しすぎるあまり、本来の目的である「開発ライフサイクル全体においての全ての活動を、モデルドリブンで行おう」という事が意識の中から薄らぎつつある現状を、危惧されての発言かもしれません。もちろん、様々な考え方・立場の方がおられるので、一概には言えませんが。
OMG の会長兼 CEO である Richard M. Soley 氏は、基調講演の中で次のような発言をされていました。「ソフトウェアのライフサイクルの中で、分析・設計・開発等は全体の 10% 程度であり、残りの 90% は、メンテナンスとシステム同士の統合作業だ。MDA の目指すところは、異種システム間で統合しやすいシステムを作る枠組であり、コードの自動生成は MDA の一成果でしかない」と。
さて、そういった雰囲気の中、各セッションではどのような講演がされたのでしょうか。いくつかのセッションのレポートをしたいと思います。
講師: 鈴木 純一 Ph.D., カリフォルニア大学アーバイン校 (UCI) リサーチフェロー
MDA とは一体どういうものなのかを正確に把握するための MDA の説明があり、我々が MDA を実践するにあたって、戦術と戦略を考えることができるような情報の提供を発表の目的とされていました。
MDA の目指すところは、コードの自動生成ではなく、モデルの変換とその追跡可能性だとのご意見でした。コードの自動生成は、モデルの変換の結果として実現できることであり、それだけに視点を置いてはいけないとのこと。MDA 対応ツールを選択する際も、評価するポイントとして上記 2 点を挙げられておられました。鈴木氏自身は、コードの自動生成はあって越したことはないが、なくても良いというお考えでした。
MDA は、従来行われてきた開発スタイルとは違い、ソフトウェアのライフサイクル中の活動を全てモデルに依存した形で行ないます。デザインだけでなく、テスト、メンテナンスもモデル駆動で行なうことになります。それには、上記のモデルの変換という考え方が必要であり、そのモデルの連続性・追跡可能性が必要となり、それをサポートするのがツールの役割だそうです。コードの自動生成はその副産物であるとの見方です。
モデルがどのように変換されてゆくかは、みなさんご承知のとおり CIM ⇒ PIM ⇒ PSM となりますが、それらの境界がどこにあるかは、まだ議論されていないとのことです。変換に関して別の見方をすると、ドメイン軸とプラットフォーム軸を持った 2 次元面上で、2 つの要素が特化される方向に変換が行われるイメージとなります。
MDA が目指す事のもう 1 つが、関心事の分離だそうです。従来の開発では、技術者一人にドメイン知識やアーキテクチャ、プラットフォーム知識があつまり、ツールを使ってそれらをモデリングしてい ました。MDA では関心事の分離が実現できるため、ドメインエキスパート、アーキテクト、プラットフォームエキスパート、プログラマがそれぞれの強みを持つ部分の開発を行い、ツールにそれをマージさせることができます。
実際にどのように作業を切り分けるかを考えるのは、難しいことですが、MDA が狙っていることはこのような事だそうです。上記のことを実現するために、「モデルの統合」というアイデアも有効で、それは 2 日目の「H-4 : アスペクト指向の MDA」のセッションで説明されておられました。
MDA を語るとき、とかくコードの自動生成だけに注目があつまりがちです。ソフトウェア開発者にとってコード自動生成は、MDA を実践するときに最も身近に発生する事柄ですので、関心があるのはもっともです。しかし、コード自動生成ばかりに注意すると、MDA の本質を見失うと私も思います。
講演者の「モデルの変換に関心せよ」という考えには、共感しました。MDA の良いところは、CIM, PIM, PSM という概念の抽出とアーキテクチャの導出にあると思います。それはこれまで、概念モデルや分析モデルといった形で開発現場に現れていましたが、それぞれがバラバラに存在し、作られはしたが、開発を全体を通して使用されることはなかったというのが現状ではないでしょうか。
MDA は、バラバラになっていた個々のモデルをまとめ、位置付けを規定しました。これによって、分析・設計・実装に関連が生れ、モデルと実装とが一体となった開発が可能になるかと思います。
ただし、CIM, PIM, PSM が、具体的にどういうモデルなのか、どこが PIM と PSM の境界なのかの議論は、まだなされていないとのことなので、今後は、コード生成という側面だけではなく、モデリングそのものの議論も活発化してゆくことを期待しています。
講師: 細谷 竜一, 東芝ソリューション(株) SI技術開発センター SI 技術担当
システム開発の各活動の専門化は、開発の目的と体制の分断化をもたらし、結果としてビジネスゴールと IT 開発の相関を弱めました。IT の ROI が問われるようになった現在において、その相関を強めるための技術体系として MDA を議論するという発表がありました。
要求は伝わりにくく目標は共有されがたいということから、要求者と開発者の分断が起っています。そのため企業の IT システムの開発が場あたり的なものとなってしまい、「連携できない」、「一貫性のない」といったサブシステム群が産み出されるという結果になりました。しかし、会社全体の業務改善を目指すためには、統一性のあるシステムづくりが必要で、技術面からは各システムの設計の横串が必要であるとのことです。(これが、EA (エンタープライズアーキテクチャ)の発想だそうです。) ⇒ この状態のことを、MOF の M1 レイヤ上で開発していることから、M1 ワールドと呼んでおられました。
そこで、業務プロセスにあわせたメタモデルを定義し、各システムは個別にモデリングするのではなく、そのメタモデルにあわせたシステムを構築してゆくアプローチを取ります。そうすることで、ビジネス(経営)と IT システム(開発)が結びついた状態になることができるということです。ただし、メタモデルはより抽象的な思考を必要とすることから、要求者と開発者との距離がますます広がってしまうことになります。 ⇒ この状態のことを M2 ワールドと呼んでおられました。( M2 は、MOF ではメタモデル層 )
そこで、MDA の登場となります。MDA はメタモデル・モデル・実装を「結びつける」ので、前述したメタモデルを使った開発を助ける存在であるというのが、細谷氏の意見でした。つまり、MDA が要求者と開発者とを結びつけるようになるということのようです。⇒ この状態を統合された M ワールドと呼んでおられました。
細谷氏によると、EA のバックボーンとして MDA は相性が良く、また MDA は EA をサポートできる存在であるとのことです。EA と MDA との相性が良いというのはなんとなく感覚で分りますが、後者はどういうことでしょうか。EA はトップダウンのアプローチでアーキテクチャを決めますが、MDA はそれにボトムアップのフィードバックをかけることが出来るということだそうです。詳しく言うと、システム構築後に業務との整合性を検証し、その結果をメタモデルにフィードバックすることで、アーキテクチャの見直しが出来るということです。また、MDA という技術の導入の訳を EA が答えてくれるという考え方もできるのだそうで、EA と MDAのペアはうまくいくのではというご意見でした。
BMA とは、OMG の Business Enterprise Integration Domain Task Force にて策定プロセスが開始されたアーキテクチャで、ビジネスの 5W1H をモデリングするためのメタモデル標準です。これまで述べてきた、ビジネスと IT とのギャップを橋渡しする目的を持っているそうです。(上述した、EA との関係を議論するような動きはまだないそうですが。)
BMA 後の MDA は、ビジネスモデルと各システムの PIM が関連した状態になり、ビジネスゴールと結びついた IT システムが構築されることになるそうです。そのため、IT システムが企業戦略にマッチするだけでなく、ROI が計りやすくもなるというご意見でした。
会社の経営戦略をメタモデルを使ってモデリングし、その上で各 IT システムを構築することで、ビジョンを持ったシステムができるということには賛成です。MDA がその仕組みを提供するという考えにも賛成です。
しかし、システム間の連携はこれまでより改善されるかもしれませんが、IT システムと会社のビジネスとが、これで本当にマッチするようになるかというと、やっぱり「やり方による」のだろうと思います。それを言ってしまえば、なんでもそうなのですが...。
気にかかるのは、そこまで抽象度の高い問題を本当に我々が扱えるのかということです。MDA が MOF の各層の連携を取ってくれるとはいえ、誰にも理解できるモデリング (or メタモデリング) ができるのでしょうか。理解されなかった場合、レビューはどのように実施されるのでしょうか。このような抽象度の高い問題を扱うには、センスが必要です。小数のセンスを持っている人達がいただけでは、技術はなかなか広まらないと思います。MDA がそれをサポートしてくれるのかどうかは、私には判断できませんでした。
講師: 滝本 雅之/我妻 智之, (株)NTT データ 技術開発本部 先進ソフトウェアエンジニアリンググループ
「現時点で、MDA による開発が業務系システム開発に適用可能か？」という問題をテストプログラムを使って検証し、その結果をまとめておられました。また、モデル管理ツールとして、MOF リポジトリの発表と簡単なデモがありました。
TPC-Wの仕様から抜粋したインターネット書籍販売システムを、その評価ターゲットにしていました。だいたい 100 function point 程度の規模。それを、MDA スタイルと従来スタイルの 2 通りで開発したそうです。ただし分析モデルまでは同じ工程をとり、設計以降の作業を比較対象としたそうです。
MDA スタイルでは、独自に定義したアクション言語を PIM に書き、コンパイルできるコードを自動生成できるようにしたとのことです。興味深いのは、モデル自体のテストまで独自に行なったそうで、PIM から生成した XMI をパースして"決ったテキスト形式"に落とし、別に用意しておいたテストスタブ、テストケースとともに、モデルシミュレータに読み込ませるようにしたそうです。シミュレータからは、テストの結果とインスタンス一覧、およびシーケンス図が出力されるようです。
シミュレータからシーケンス図が出力されるのは、モデルのアクションを状態図やシーケンス図を使って表現せず、クラス図にアクション言語を書いていたため、シーケンスチェックをする必要があったからだそうです。この活動の当初は MDA の仕様がそろっていなかったために、そのようになったそうです。
| フェーズ | 削減率 | 考察 |
|---|---|---|
| 設計 | 27% | アクション言語を書いたにもかかわらず、コストが下げられたのは、ガイドラインと、PI フレームワーク/ユーティリティ(PIM から PSM(J2EE) への変換および、社内ライブラリの使用をサポートするユーティリティ)があったから。 |
| 実装 | 33% | 本来なら 100% になるはずであるが、UI まわりや、Oracle との接続部分は手作業で実装することになったから。 |
| テスト | N/A | 単純比較できないため、評価基準を模索中。 |
ただし、PIM 変換ルールの作成時間は評価していないそうです。まとめとしては、下のような事柄を挙げられていました。
また、課題としてモデルの構成管理を挙げておられ、その解として MOF リポジトリの紹介がありました。
MOF リポジトリは、簡単な説明とデモがあっただけですので詳細は省きますが、OMG の Object Application Awards 2003 の最優秀賞を受賞したツールだそうです。メタモデルをツールの中に登録し、それと紐づいたモデルを格納できるものだそうです。デモでは、Rational Rose のプラグインとして動作し、モデルを格納できる様子がありました。ファイル単位の管理ではなく、クラス単位の管理ができるようになるとのことです。ただし、まだ永続化ができない等、これからの課題も多いようです。
アクション言語を独自に作って、振舞いを記述していましたが、Java を使った業務系システムが対象の場合、完全に動くコードをモデルから 100% 出力させようとすると、現状ではこのようにせざるを得ないのでしょうか。
また、そこまでがんばって自動出力を行なっても、実装の 3 割程度しか工数を削減できなかった点にも注目したいと思います。実装にかかったのはインタフェース部分のようですが、この部分は、MDA が発展してもなかなか自動化できない最後の砦となりそうだと思います。また、インタフェース部分は実装にかかるコスト(=時間)が、他の部分よりもかかりますから、他のビジネスロジックが自動生成されても、実装コストの大幅減にはならないと私は考えます。
MDA を評価する場合には、そのソフトウェアのライフサイクル全体を通して見ないと、なかなかメリットが見えてこないのではと思いました。
MOF リポジトリの方は、今後、このような構成管理ツールは登場してくるだろうなと思いました。まだまだ研究の余地はありそうですが、モデルの変遷を追いたいのは今の開発現場でも同じですし、良い製品が出てくることを期待します。
講師: 鈴木 純一 Ph.D., カリフォルニア大学アーバイン校 (UCI) リサーチフェロー
1 日目に行われた「B-1 : MDA 実践のための各種アプローチと技術、技法」と対になるセッション。セッションの最初は、「B-1」でお話されたことのおさらいが簡単にあり、今回の話題の中心である MDA における関心事の分離とはどういうことかというご説明と、ご自身が携われた SDO プロジェクトを事例紹介として挙げられていました。
関心事の分離とは、文字通り異った種類の関心事を分け、分離されたモノどおしの関連を粗にする事を言います。例えば、EJB ではデプロイメント(配置)とビジネスロジックの開発が分離されており、それぞれを別のデベロッパーが担当できるようになっています。
アスペクト指向では、クラス間にまたがった関心事をアスペクトとして実装し、アスペクトウィーバー (Weaver) でそのアスペクトを組み込むことで、あちこちのクラスで同じような処理を書く必要がなくなります。MDA におけるアスペクト指向とは、現在実装時に実施しているアクティビティをモデリング時に実施しようということのようです。
鈴木氏は、OMG のサブグループである SDO (Super Distributed Objects)* というプロジェクトで、アスペクト指向を使ってモデルの統合をされました。このプロジェクトでは、アスペクト用の UML プロファイルを自身で定義し、その定義に基いて変換ルールを作成し、モデル変換時に複数のクラスを統合しました。行った作業は、上記プロジェクトで開発した SDO フレームワークと、Bionet ** と呼ばれる自律型ネットワークシステムの 2 つのモデルをマージしたそうです。具体的な例の 1 つを挙げると、Bionet のいくつかのクラスが、SDO のあるクラスを継承するように waving したとのことです。
結果、アスペクト指向を使ってモデルを統合するアイデアはうまくいったそうです。複数のアスペクトを組み込むときには、順番を手作業で行う必要があるなど、全自動で全てマージするには克服する点はありますが、実際に waving でき、UML プロファイルさえ整えれば、今でも実現可能なアプローチであるとの発表でした。
アスペクト指向の考え方を使い、モデルを統合するというのは面白い試みだと思いました。ただし、そこまでするかと感じたのも事実です。あまりにもアカデミックな内容であるとともに、現在の段階では非常に労力を要するので、開発活動全体として本当にプラスの効果を得られるのだろうかと感じたからです。
しかし、MDA が真に受け入れられ、全ての開発活動がモデルベースで行われるようになると、このようなテクニックも必要になる時がくるのでしょう。全てがモデル駆動で行われた場合に、どのような考え・技術が必要になってくるかの全貌はまだ見えませんが、コーディング時に行なってきた活動のいくつかは、モデルベースで行なってゆくはずです。企業で実践する場合、手作業でがんばるのは現実的ではありませんから、やはり、キーポイントはツールでどこまでサポートしてくれるかでしょうね。
今回も UML ロボットコンテストが同時開催されました。今年でもう 3 回目になります。あいかわらずロボコンは盛況で、40 チーム程の参加があったそうです。今大会から新しい取り組みとして、モデリングの発表が走行の前に行われるようなりました。これは「優秀なモデルはどのような走行をするか」といった見方ができるようにするための工夫だそうです。(大会関係者談)
弊社も 2 連覇を目指し、精鋭部隊(?)を送り込みました。結果は、モデリング部門で「シルバーモデリング」(第 3 位)を受賞。レース(タイムトライアル)部門では、残念ながら完走することはできませんでした。参加申し込みから大会までの奮闘記は、来月号 (2004 年 6 月号)に掲載される予定です。おたのしみに。
やはり、本年も MDA 一色といった雰囲気でした。ただし、聴講したセッションが業務系ばかりで 組み込み系のセッションがなかったためか、「アクション言語を積極的に使い、コードを 100% 自動生成して生産性を上げてゆこう」といったお話はありませんでした。それよりも、今年は全体を通して、メタモデルが前面に出されている感があり、より抽象度の高いところに関心をシフトしてゆこうといった動きがあるように感じました。
しかし、組み込み系のセッションに参加すると、違った印象を受けるかもしれませんし、上記セッションを聴講した者の一意見と受け取って下さい。ただし、ビジネスモデリングのトラックが設けられたり、「エンタープライズ」や「企業戦略」といった言葉がセッションのタイトルに見受けらるようになった事を考えますと、「業務分析をして、会社全体のモデリングをし、さらにメタモデルを開発して、その上でシステム構築を考えてゆく」というのは、今後、トレンドになってゆくのかもしれません。
ただしそういった場合でも、より抽象度の高いモデリング能力だけが求められるようになるのではなく、プラットフォーム依存のコーディング能力やモデリング能力(変換ルール構築など)を持ったエンジニアも、当然必要になるでしょう。MDA が成功した場合には、ソフトウェアの世界に分業化の波がやってくるかもしれません。
| © 2004 OGIS-RI Co., Ltd. |
|
