ObjectSquare

[レポート]


Modeling Forum 2004 参加レポート


はじめに

日本初のモデリングに特化したフォーラムとも言える Modeling Forum 2004 が、2004 年 9 月21, 22日の 2 日間、東京コンファレンスセンター/品川で開催されました。モデリングに特化しているということで、そのセッションも、ビジネスモデリングあり、開発プロセスあり、教育あり、MDA あり、、、とまあ盛りだくさんの内容でした。

ここに、広場編集委員が聴講したセッションの内容やフォーラムの雰囲気を、所感を含めて記したいと思います。

もくじ

C-02 : 次世代開発手法 Software Factories

講師: 萩原 正義氏, マイクロソフト株式会社 デベロッパーマーケティング本部 ソフトウェアアーキテクト

内容

DSL ( Domain Specific Language )

マイクロソフトが提唱する開発方法論、Software Factories では、UML のみを使ってモデリングをするのではなく、それぞれの問題領域に合ったモデリング言語、つまり DSL を使うべきであると考えているそうです。

また、特定の DSL から別の DSL へ変換したり、ソースコードを自動生成するための DSL 開発環境が必要と主張していました。

プロダクトラインアーキテクチャ

プロダクトラインアーキテクチャに基づく開発プロセスは、特定システムに依存しないプロダクトライン開発のプロセスと、特定システムに依存したプロダクト生産のプロセスに分離しています。

プロダクトライン開発のプロセスでは、FODA ( Feature Oriented Domain Architecture ) という考え方に基づき、再利用可能な要求( Feature )を分析し、この要求を実現するためのアーキテクチャや DSL やプロセスを設計、実装するそうです。このアーキテクチャ、DSL、プロセスの一まとまりを Asset として定義します。

プロダクト生産のプロセスでは、特定システムの要求をもとにして、適切な Asset を選択し開発するそうです。

所感

「 UML ですべてのモデルを定義できるわけではない、必要に応じて UML 以外のモデリング言語を使うべきだ」という考え方には賛成です。UML 初心者は「 UML でできることしかしない」、「 UML でできないことがあるから UML は悪い」という勘違いを持つ方がいるので、「 UML 以外も重要」という考え方が広まるのは良いことと思います。ただ、DSL がその唯一の解決策かというと、そうではありません。

これまでの OMG の活動の結果、UML ではモデリングできない問題領域をモデリングするための UML Profile が多く策定されました。UML Profile とは、UML を特定の問題領域用にカスタマイズする仕組みです。UML 2.0 では、より UML との整合性が保たれた UML Profile を策定できます。

これから、UML Profile が主流になるのか、DSL が主流になるのか。お手並み拝見といったところでしょうか。

( 山内亨和 )

C-04 : MDA + AOP、その目的と動向

講師: 鵜林 尚靖, 九州工業大学 情報工学部 知能情報工学科 助教授

内容

まず、構造化手法、オブジェクト指向手法といったソフトウェア開発手法の変遷について振り返りながら、アスペクト指向手法の位置付けについて話されました。新しい手法というのは、今までのものを否定するものであると考えられがちであるが、アスペクト指向手法は、オブジェクト指向を否定するものではありません。アスペクト指向手法は、オブジェクト指向の弱い部分を補うものである、とのことです。また、構造化手法に対するアスペクト指向というものも存在すると話されていました。

アスペクト指向は、考案されてから 10 年ぐたい経つが、まだ入り口にある状態であるとのことです。1967年 Simula の言語に初めて導入されたオブジェクト指向の概念と比べると 10 年はまだ短いとのことでした。

1. オブジェクト指向からアスペクト指向へ

オブジェクト指向が持つ問題点がアスペクト指向によってどのように解決できるかを中心に説明が行われました。

まず、理想的なモジュール化のメカニズムについての説明が行われました。理想的なモジュール化のメカニズムというのは、要求から実装に渡ってシームレスであるということです。つまり、以下のようなモジュール化のメカニズムが必要であるとのことでした。

オブジェクト指向は優れたモジュール化のメカニズムであるが、これらの要求のすべてを満たすことはできません。その理由を Tomcat のプログラムを例に説明されていました。

Tomcat のプログラムを解析すると、XML の解析処理については、一箇所にまとめられているとのことです。これは、オブジェクト指向によって XML の解析処理に関する関心事を、一箇所にまとめることができるということを意味しています。

一方、ログ処理に関しては、複数のオブジェクトにまたがっていて、一箇所に集まっていません。数多くの場所に分散しています。これは、オブジェクト指向によって、ログ処理に関する関心事を、一箇所にまとめることができないためです。
ログ処理を一箇所に集めるために、たとえ、ログ処理用のオブジェクトを作成したとしても、そのログ処理用のオブジェクトのサービスを呼び出すコードが分散してしまい、結局は一箇所に集めることができないとのことでした。

このことから、オブジェクト指向は XML の解析処理などの機能要件に関するカプセル化には優れているが、ログ処理などの複数のオブジェクトにまたがる関心事を表現することには向いていないとまとめられていました。そして、オブジェクト指向に対するこのような問題意識から AOP (アスペクト指向言語) が生み出されたと説明されていました。

ちなみに、複数のオブジェクトにまたがる関心事は、横断的関心事(Crosscutting Concerns)と言われます。横断的関心事の例としては、ログ処理の他に以下のものを挙げられていました。

さて、オブジェクト指向が抱える問題点を克服する AOP ですが、同期制御、資源共有、性能最適化など複数のオブジェクトにまたがる関心事をアスペクトというモジュール概念を用いて記述するプログラミング方式であると説明されていました。

AOP では、通常の機能を実装するオブジェクトと、複数のオブジェクトにまたがる関心事を実装するアスペクトの 2 つを別々に作成します。そして、それらのオブジェクトとアスペクトとを weaver と呼ばれる一種のコンパイラを使ってコンパイル( weaving と呼ばれます)し、オブジェクトとアスペクトを紐づけて、実行可能なプログラムを作成すると述べられていました。

つまり、AOP を使えば、先ほどのログ処理に関するコードをアスペクトとして一つのモジュールに記述する(カプセル化する)ことができ、さらにそれをいくつかのオブジェクトのモジュールの適切なポイントに組み込むことができるようになるということです。

この AOP が持つべき適切なポイントに組込むための仕組みとして、JPM (Joint Point Model) を取り上げられていました。JPM は、ジョイントポイント、ポイントカット、アドバイスの 3 つから構成される概念です。
それぞれ以下のように説明されていました。

その他、 AOP に関して 2 つのことを紹介されていました。

一つ目は、AOP を実現する言語処理系です。AOP で有名な AspectJ 以外のアスペクト指向言語として、以下の言語処理系を挙げられていました。

J2EE のアプリケーションサーバーである JBoss-AOP が挙げられているように、J2EE の方面で Aspect 指向が取り入れられているとのことです。
J2EE もアスペクト指向の一面を持っているといえると説明されていました。

二つ目は、ソフトウェア開発工程全体に関係する AOSD (Aspect-Oriented Software Development) です。セキュリティに関する要件などを例として挙げながら、上流工程に関するアスペクトも存在すると述べられていました。
また、ユースケースとアスペクトは関係が深いとも説明されていました。ユースケースは複数のオブジェクトにまたがるもの。従って、ユースケースは、機能要件に対するアスペクトであると考えることができるということです。
また、同様に非機能要件もアスペクトとして考えることができると述べられていました。

2. オブジェクト指向から MDA へ

アスペクト指向の説明に時間を割かれたため、MDA に関しては簡単に紹介されました。

MDA とは、実装技術(J2EE や .NET など)から分析 / 設計を独立させ、設計情報が実装技術に左右されないようにする技術であるとのことです。
また、再利用の単位を実装に依存しないようにしていくための重要な技術であるとも説明されていました。

さて、このような MDA を実現するための鍵として、重要になってくるのが、厳密なモデル表記を与える MOF と OCL, PIM から PSM に変換するための厳密なモデル変換を定義する QVT (Queries, Views, and Transformations) であると説明されていました。
「動く」と「使える」は違う意味なので、QVT のモデル変換技術が十分な性能を満たさない限り、使えないとも述べられていました。

また、QVT のようなモデル変換のマッピングルールがアスペクトに相当すると述べられ、MDA とアスペクト指向の関係性についても言及されていました。

アスペクト指向とMDAの融合 〜研究事例紹介〜

大学で研究している AspectM の紹介です。こちらも時間の都合上、簡単に紹介されています。

AspectM というのは、アスペクト指向のメカニズムに基づいて MDA のモデルコンパイラを構築する方式を採用したツールです。つまり、モデル変換のマッピングルールをアスペクトとして捉え、モデル変換のためのマッピングルールをアスペクト指向を支える JPM で定義できるようになっています。また、AspectM では、アスペクト図というものが考えられています。これは、JPM のジョイントポイント、ポイントカット、アドバイスを表記できるように、UML メタモデルの Classifier を拡張して定義したものです。簡単に言えば、クラス図のクラスの表記を使って JPM が表現できるようになっています。

AspectM は、XML ベースのアスペクト指向モデリング言語であると説明されていました。つまり、UML で表記された PIM のクラス図を XMI 形式に落とし込み、アスペクト図のモデルから作られる XSLT 変換ルールをもとに、PSM の XMI 形式のモデルを作成し、UML で表記された PSM のモデルを得るという方式です。

また、AspectM のメリットとして、以下のことを挙げておられました。

これは、OMG で考えられている QVT のモデル変換が、モデル作成者自身がアプリケーションの特性や目的に応じてモデル変換規則を定義するのが難しく、主にモデルコンパイラを開発する人のための専用言語という位置付けになっているという課題を解決するものであると述べられていました。

4. まとめ

アスペクト指向はオブジェクト指向と同じ道を歩んでいると述べられていました。そして、AOP が一段落すれば、モデリングとしてのアスペクト指向の研究が進んでいくだろうと予測されていました。

所感

アスペクト指向についてまだ関心が薄いのか、本セッションへの参加者は 200 人程度収容できる会場に 6, 7 割といったところでした。

本セッションを受講するまでは、アスペクト指向、MDA については聞いたことがある程度の理解でしたので、今回は勉強モードのスタンスでの聴講です。今回の一番の収穫は「アスペクト指向と MDA は別々の概念ではなく、同じ枠組みの中で扱うことができる」ことを理解したことです。

参考

( 永田博靖 )

P-14 : Visual Studio 2005 Team Systemにおけるモデリング機能

講師: 成本 正史氏, マイクロソフト株式会社 デベロッパーマーケティング本部 マネージャー アーキテクトエバンジェリスト

内容

SOA によるシステム構築を実現する上で、ソフトウェア開発ライフサイクル全般をサポートするツールが必要です。この機能を提供する Visual Studio 2005 Team System のモデリング機能を中心に紹介するセッションでした。

Dynamic Systems Initiative ( DSI ) について

Dynamic Systems Initiative ( DSI ) は、構築、配布、運用といった、分散システムのライフサイクルについて、自動化、簡素化の仕組みを実現する取り組みです。

例えば、Microsoft 製品の統合や、ハードウェアベンダーなど DSI のパートナーとの提携があげられます。また、UML だけで全てを解決するのではなく、適切なモデルを用いて、自動化、簡素化に向けて取り組んでおられるとのことでした。

System Definition Model ( SDM ) について

System Definition Model ( SDM ) は、分散システムを定義するために用いるモデルです。SDM は、開発用のドキュメントだけではなく、運用、配布に関することも定義します。システムのライフサイクルには、開発だけではなく、配布や運用管理も含まれるため、あらかじめ定義し、配布や運用管理の自動化を考慮します。

Visual Studioを用いると、ビジュアルな操作で、タグ形式の SDM を記述することが可能です。また、変更要求が発生した場合に、SDM に取り込めるなど、自動化、簡素化を狙った SDM 駆動型のライフサイクルを実現できます。

講演では、SDM のサンプルもご紹介いただきました。

今後の展望

UML など 1 つだけのモデリング言語で事足りると考えているのではなく、それぞれのモデル対象に最適なモデリング言語を使っていくべきだということでした。ソフトウェアライフサイクルにおいて、SDM に基づいた開発アプリケーションや管理アプリケーションを用いた包括的ソリューションを目指していくとのことです。

所感

IT 業界をリードする Microsoft 社の講演ということで、みなさん熱心に耳を傾けておられました。

ソフトウェアライフサイクルに必要となってくる様々なツール群が、親和性のある統合されたものになり、複雑さを緩和し、手作業を減らして行く方向へ向かっていくことは、魅力的なことに思えます。

新しい言語を、また覚えなければならないのか、といったエンジニアの嘆きが聞こえてきそうですね。
とはいえ、SDM のメタモデルはオブジェクト指向でよく出てくる汎化、継承、カプセル化、ポリモフィズムといった考え方を採用しているとのことでしたので、オブジェクト指向を理解しているエンジニアにとって、とっつきやすいのではないかと思いました。また、SDM はビジュアルな操作で取り扱えるということでしたので、Visual Studio 2005 Team System は、少ないオーバーヘッドで導入できるものだったらいいなと期待しています。

参考

( 山内奈央子 )

P-15 :ユーザ企業 IT 部門にとっての UML モデリング 〜その限界と可能性〜

講師: 藤井智弘氏, 日本アイ・ビー・エム株式会社 ソフトウェア事業ラショナル事業部 SDPテクノロジーエバンジェリスト

内容

UML は「コードを書かない」エンドユーザ IT 部門のエンジニアにとって、役に立っているのか、これから学習する価値は、どこにあるのか。コードを書かない IT 部門の方々が UML で何ができるか、あるいは何をすべきかについて、講演されました。

エンドユーザー IT 部門をとりまく現状

IT をとりまく現状として、統合や分社化などの経営環境の変化や、急速に発展する技術、また、低コスト化だけではなく、品質への要求などがあげられます。
その中で、エンドユーザー企業の IT 部門では、エンドユーザーと SIer との仲介役としての役割が求められています。 また、IT 部門は、ソフトウェア開発のみならず、運用や既存システムとの統合も含めて考慮しなければならない現状を説明されました。

IT 部門で UML を利用する際のキモ

モデル駆動開発を成功させるキモとして、どのようなモデルを、いつ、どの場面で、何の目的で利用するのか、、、といった 5W1H の重要性を挙げられました。

一口に UML のモデルと言っても、ビジネスレベルのものから実装を定義したレベルのものまで詳細度は様々です。IT 部門の責任範囲はどこまでか、SIer にはどこから任せるのか、を見切ることが重要です。開発対象業務の特徴(例えば、どの業務内容の変更頻度が高いか、など)は、SIer では判断できないため、IT 部門が判断する必要があります。その判断した結果をモデルに反映できるような責任分担が必要だ、と説明されていました。

また、UML を用いて、1 つのことを何通りにもモデリングすることができます。自社の中で、どのような方針でモデリングするのかといったルールが必要になってくるとのことでした。

所感

UML は表記法ですので、UML をどのように使うのかといった目的を、まず明確にすること、という藤井氏の意見には非常に納得しました。ここが不明確なままプロジェクトが進むと、モデラーごとに粒度がまちまちなモデルが出来上がってしまい、プロジェクトは右往左往することになるでしょう。ソフトウェア開発を行う際には、作業を行うためのプロセスの定義や、成果物のガイドラインが必要である、というメッセージが伝わってきました。

しかし、講演では、エンドユーザー IT 部門にフォーカスが当てられた話になっていたため、あまり詳しくは出てきませんでしたが、開発手順やガイドラインが必要なのは、エンドユーザー IT 部門が担当する部分だけではありません。もちろん SIer が担当する部分も、開発プロセスやガイドラインが必要です。
単に開発プロセスが定義されていればいいわけではありません。エンドユーザー IT 部門と SIer との担当わけの際には、それぞれつながりのない開発プロセスを採用してしまうことのないように注意が必要です。例えば、エンドユーザー IT 部門が、彼らの開発プロセスにおける「分析モデル」までを担当するとします。その後、SIer が SIer の開発プロセスにおける「詳細設計」をすることにしたとしましょう。エンドユーザー IT 部門が「分析モデル」と呼ぶ成果物と、SIer が「詳細設計」と呼ぶ作業のインプットは果たしてマッチするものでしょうか?
ソフトウェア開発プロジェクトを行う際には、トータルで見て、一貫性のあるソフトウェア開発プロセスが必要なのだなと感じています。

参考

( 山内奈央子 )

E-04 :旅館予約業務における業務プロセスと情報モデル

講師: 飯田善久氏, 旅行電子商取引促進機構技術委員長 成蹊大学工学部 教授

内容

ECOM : 旅行商取引推進機構 ( www.travel-edi.com ) が行った旅行予約システムの EDI に関する研究プロジェクト「旅館 ebXML 共同研究プロジェクト」で行った旅行業に関するビジネスモデリングの報告でした。

背景としては、欧米の旅行予約システムが、ホテル、航空などの交通機関の予約を旅行代理店から直接行えるのに対して、日本国内は依然として、旅館や交通機関がブロックと呼ばれる予約枠を手作業で各旅行代理店へ配分しているという実情があるからだそうです。この場合、ある旅行代理店で割り当てられたブロックが予約で埋まると、旅館や交通機関へ追加ブロックの割り当て依頼し、旅館や交通機関の担当者は他の旅行代理店からの追加ブロックの割り当て依頼と調整して、再度各旅行代理店へ配分するという、非常に効率の悪い作業の流れになります。最近では国内の旅行代理店のインターネット予約システムで旅行代理店からホテルや交通機関を欧米のように直接予約できているように見えますが、実は昔ながらのブロックの割り当てが行われているのが実情だそうです。

そこで、旅館 ebXML 共同研究プロジェクトでは、欧米のように旅行代理店が旅館や交通機関に直接予約できるようにするためのビジネスモデリング ( 標準 XML スキーマの定義 ) を行いました。

モデリングのメンバーは旅行業者、ホテルや旅館の方、システム開発者、ECOM 、事務局、用語を定義するドメインエキスパート、モデルとしてまとめるテクニカルモデラーという役割で構成されます。

苦労した点として次のような発表がありました。

  1. 当初、業務を大まかに階層化して分類していたが、それだけではデータ交換するモデルを作成することができなかった。
    そこで、追加で業務フロー ( ビジネスプロセス ) をモデリングすることにしたそうです。
  2. 予約のパターンが欧米よりも多く複雑である。
    たとえば、旅館は「食事付き」とか「送迎あり」とか欧米には無い属性があります。これは静的モデル ( クラス図 ) に予約パターンという概念を取り入れるという工夫をしたそうです。
  3. パック旅行
    パック旅行という商品とそれを構成する部屋、食事、送迎などをどのようにモデリングするかが問題になり、商品と素材という、全体と部分の関係と先ほどのパターンを組み合わせてモデリングすることで解決したそうです。

当初の成果物と最終成果物を見せていただいたのですが、当初は UML ではないようでしたが、最終的には UML になっていました。
成果として「考え方が整理され、議論が共通の基盤で行えるようになった」とのことです。

所感

私が参画している SI の現場では、要求定義をするユーザの方やメインフレーマー出身のエンジニアの方から、UML に対する一方的な拒絶反応を受けることがありますが、このセッションのようにオブジェクト指向を知らない旅行業者、ホテルや旅館の方であっても、プロジェクトの進め方に気をつければ、UML を使ってビジネスモデリングが可能であることがわかり、ちょっぴり勇気付けられました。

( 正木威寛 )

全体を通しての所感

Modeling Forum 2004 のテーマであるモデリングは、システム開発という広い分野の中で、新興の、狭い、直接利益には結びつきにくい分野です。そのため、このフォーラムに参加する前は、「果たしてどれだけの人がモデリングに期待をしていて、どれだけの人が参加するだろう?」という興味とも心配とも言える複雑な気持ちを持っていました。
当日、この心配が取り越し苦労であったことを認識したわけですが、それとともに、これからのエンジニアはモデリングとどうかかわっていくべきか、についても考えさせられました。

今回の Modeling Forum 2004 のセッションでも分かるように、一言にモデリングと言っても、ビジネスモデリングや SOA や AOP などに、様々な分野に急速に広がっていっています。UML Profile や MDA や DSL などの特定の分野向けのモデリング基盤も浸透していっています。
一昔前までは、UML とオブジェクト指向、ソフトウェアの知識だけ分かっていればモデラーとして仕事ができたかもしれません。しかし、このままモデリングの分野が広がっていくのなら、それと同時にモデラーも専業化が進んでいくのでしょう。

近い将来、「自分は○○○モデラーだ」と言えるために、○○○そのものの知識だけではなく、○○○をモデリングするためのスキルが身に着けていく努力が必要なのかもしれません。

参考




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