Podcastについて

ソフトウェアのアーキテクチャやモデリングに関するPodcastがいくつか有ります。私の気に入っているのは次のものです。

• software engineering radio

もしiTunesをお使いであればsubscirbe出来ます。どなたか日本でも同じようなことをしませんか？

関連してですが、やはりiTunesでOOPSLAをキーワードにして検索すると、2007年と2008年の講演内容の一部が公開されていることが分ります。

どちらも全部つきあうのは疲れますので、講演者やタイトル（分野）でつまみ食いされてはどうでしょうか？

handbook of software architectureについて

ソフトウェアアーキテクチャの本は沢山出版されていますが、このURLのことはご存知でしょうか？

• handbook of software architecture

有名なBoochさんが気になる各種アーキテクチャを溜め込んで整理されています。内容にアクセスするには登録が必要です。今回はこの紹介だけです。

viewとviewpointについて

viewとviewpointという言葉を聞かれた事があると思います。ソフトウェアやシステムのモデリングでは、viewpointというのは対象のある側面だけに注目（そしてそれ以外は気にしない）したモデル（仕様）を書く場合のその注目した側面のことです。例えば、情報要素だけに注目した情報のviewpoint、機能要素にだけ注目した機能viewpoint、物理的な配置に注目した物理viewpoint、またビジネスアナリストの立場からビジネスプロセスviewpointなどが考えられます。viewpointと言わずにperspectiveという言葉を使う場合もあります。viewというのは、そうやって決めたviewpointから対象を眺めた場合に見えるもの、つまりviewpointに限定したモデルないし仕様ということになります。wikipediaには、view modelというエントリがありますのでご覧ください。

いつ頃からこれらの概念が意識されるようになったのか確かな事は分かりませんが、私はISOのRM-ODP標準化活動に参加するようになってなじみの考え方になりました。RM-ODPではviewのことをviewpoint specificationと言っており、五つの標準viewpointをもうけています。その後、IEEE 1471というview/viewpointを一般的に扱う標準がIEEEで作成され、これがISOに持ち込まれて国際標準にするための作業が行われているところです（ISO/IEC JTC1/SC7というのがその検討の場になっています）。

UMLの世界にも“4+1” view modelというものがあり、UMLの標準文書でModelというPackageを拡張する要素を見ると、属性としてviewpoint（String）を書けるようになっています。つまり、ModelというPackageの中に各viewpointモデル（view）を含めることで、対象を複数の視点・観点から見た場合のモデルを構成する事が出来るようになっています。

分かり易いところでは、論理的なモデル図と物理的な配備図をviewpointの異なる別のモデルとして書く事が出来ます。

ただ気をつけるべきは、viewpointを分けて書いたとしても所詮同じ対象を書いているということです。従って、何らかのつながりがあるはずです。例えば、建築物の図面で正面図と側面図というのあり、前から見えるものと横から見えるもの（明らかに違います）を別々の図面で書きますが、正面図の長方形の屋根部分は、側面図で30度の傾きを持っているといったつながりがあります。ソフトウェアやシステムのモデルでも同じことが起きる筈です。RM-ODPではcorrespondence（相関関係）と言いますが、対応付けやマッピングと言う言葉で済む場合もあります。各viewモデルに加え、相関関係も併せて書く事で、モデルや仕様として完成度の高いものになり、うまく行けばモデル駆動開発（MDD）における高品質な入力情報になると思います。

モデリング記法いろいろ

UMLはUnifiedモデリング言語ですがUniversalモデリング言語ではありません。UMLを使うと普通必要な範囲のモデリングはほとんどカバーできますし、UML2.0になって基盤となるセマンティクスもしっかりしたものになっています（複雑すぎると言う批判も有りますが）。しかし、必ずしもUMLを使わないとモデリングが出来ない、というものでもありません。

例えば、XMLでモデリング対象の構造をしっかり規定すればUMLのクラス図と同様の効果を持つ文書構造が出来上がります。もっと緩やかにオフィス文書の延長でPowerPointやExcel、更には単純な文章で記述することも可能でしょう。書き方がどれだけ厳密かという点に違いが有ると思いますが、入りやすさという点では案外まずUML以外で書いてみるのは早道かもしれません。後で厳密さを上げてゆけば良い訳ですから。

メタモデリングツールの代表としてこれまで良くEMFを取り上げていますが、EMFのネイティブな（メタ）モデルの形式（ecore形式）はXMLです。それなら、最初からテキストエディタのテンプレート機能等を活用してXML文書の形でモデルを作成し、欠けている箇所をXML文書変換ツールで変換・補足してゆけば、ダイアグラム系ツールのお世話にならずに済みそうです。テキストベースだと何が書いてあるか分り難いという声もありますが、ソースコードもテキストです。ダイアグラムにすれば何でも途端に理解出来るようになる、という訳ではありません。

しかしながら、ダイアグラム系ツールの利点はやはり一見して全体が見渡せるという点だと思います。ダイアグラムが複雑になった場合には、ハイレベルで全体像を表現するようなダイアグラムを用意することが必要になると思います。そうしないと、XMLのようなテキスト系の記述の方がシンプルに思えてきます。

DSLの世界では両方のアプローチがあります。またMicrosoftのOsloのM言語はLanguage-oriented programmingという分野に入るようですが（wikipediaで調べてみてください）この世界は今のところテキスト中心のようです。

結局、モデリング分野で仕事をする人はやはり両方扱えるようにしておかないといけないですね。

SOAモデリングについて

今月（2008年12月）開催されたOMG会議の結果概要がプレスリリースの形で出ています。OMG Advances Standards at Technical Meeting; Elects New Board Members in Santa Clara, Calif  です。そして、その中に注目のエントリがあります。それがUPMS Submission（UML Profile and Metamodel for Services）です。

この仕様はSOAモデルをUMLの拡張（プロファイル：ステレオタイプ等）で書けるようにするもので、そのためのメタモデルも含まれています。これまでいろいろな人がいろいろな方式でSOAモデルを書いており、それを読む立場の人は、まず書き方を理解するところから入っていました。それが、標準化の目処が立った、ということです。OASISのSOA参照モデルなども参考にしながら作成されており、またWeb Servicesのモデルにならないように配慮してあります。現段階はOMGの標準化プロセスではアルファ版という位置づけであり、見直しを経てベータ版、最終承認を得てOMG標準仕様、という先があります。UPMS改訂提案文書（仕様案）は上のプレスリリースに含まれるURLから入手出来ます。

UML Profileですので、既存UMLツール用にProfileデータを作成すれば直ぐに試す事ができますし、ツールベンダもきっとこのProfileを組み込んだバージョンアップをしてくると思います（保証は出来ないので「期待します」が正しい言い方かもしれません）。是非ともお手持ちのUMLツールでお試しあれ！

組み込みシステムとモデリングについて

個人的には余り経験がありませんが、モデリングツールの適用先ということで良く組み込みシステムが話題になります。民生品では携帯電話やロボットなどですが、海外では軍関係の領域でいろいろあるようです。考えてみると、単純な券売機や自販機の状態遷移に基づく動作など、もともと向いていたのかもしれません。

iUMLというツールがありますが、基本的にクラス図と各クラスの状態遷移と動作を記述するアクション言語から構成されています。他のUMLダイアグラムを使わないという意味で、UMLサブセット+スクリプトということになりそうです。こうなると、基本となるクラスの選び方・設計が「非常に」重要になります。

メタモデリングツールも良く組み込み系で使われています。多分、電子部品等の組み合わせをコンポーネントとそのポート同士のワイヤリング・接続でうまく表現出来るためではないかと思います。航空機産業でも使われている模様ですし、当然ながら自動車産業でも利用されている筈です（現場は知りませんが）。

先日ロボットのミドルウェアに関する入門書を眺めましたがモデリングを使った説明がありました。興味深かったのはプラットフォームのモデリングで、エンタプライズシステムがWebアプリケーションをマルチティアの形で実現するように、単純には入力・処理・フィードバックというような制御ループの構造をベースにしているようだという点です（実際はもっと複雑なものだと思いますが、分かり易い説明でした）。

（エンタプライズシステム同様）組み込みシステムでも、どんなモデルをどんなプラットフォーム（を抽象化したものやフレームワーク）にマッピングするか、がポイントのようです。モデリングツールは使う人の好みで良いのではないかと思うようになってきました。

本の紹介

最近「読んだ＋読みつつある」モデリング関連の本をご紹介します（私の場合本は買い求めて安心するタイプですが、これらは読んでいます）。

1. Domain-Driven Design (E. Evans)
2. Domain-Specific Modeling – Enabling Full Code Generation (S. Kelly, J-P Tolvanen)
3. Business Modeling – A Practical Guide to Realizing Business Value (D.Bridgeland, R. Zahavi)

最初のは有名なDDD本です。何しろ分厚いので途中で一休み中。なかなか進展しません。DDDに関する幾つかの疑問点（Domain ObjectベースのUIで大丈夫か、workflowやbusiness processのようなcontrol機能はどこに入るのか、等）を解消させたいのですが、時間がかかりそうです。

二つ目はメタモデリングツールの草分けであるMetaCaseの人が書いた本です。UMLのような汎用モデリング言語ではなくDSMのアプローチによりアセンブラから高級言語に移行したのと同等の生産性向上が実現出来るという主張は素晴らしい。彼らのメタモデリングのツールは良く出来ていると思いますが、コード生成のためには、Domain Frameworkを用意すること、Code Generatorを開発することが必要で、出来る人でないと出来ないかも、という印象。実際に使った方の意見をうかがいたいと思います。

三つ目は米国ユニシスの方によるビジネスモデリングの本。BMMについても触れているし、書こうとしているものは良しです。ただ、難しいのだろうと思いますが、具体例に近いようなダイアグラムが余り見当たらず、読者に（読んで理解出来る程度の）経験や背景知識を要求する本のようです。実は以前このような本を出版するという話を聞かされ、この本の内容にそったスライドを見せてもらった事がありました（もっと分かり易かったかもしれません）。ところで、著者の一人のZahaviさんは昔Essential CORBAを書いた方です。

モデリングツールについて

毎日何か書こうと思っていましたが、やはり無理でした。　：）

ということで今回は軽い話題にし、私がこれまでに触れた事のあるモデリングツールについて並べてみます。

UMLツールでは

• Rational Rose
• Rational Software Modeler
• Objecteering
• MagicDraw
• Enterprise Architect
• PatternWeaver
• omondo
• Papyrus
• Topcased

メタモデリングツールでは

• GME/gems
• eclipse EMF/GMF

そしてMDDツールですが、まだいろいろ試している最中で（まだ使い込んだものがありません）、納得したものが現れた時点で報告することにします。

UMLツールには、簡単なコード生成機能を備えるもの、クラス図をecore形式でexport出来るもの、GMF的機能を備えるもの、など各種あるため製品のデータシート等は良く読んで選ばれればと思います。またアドオンやプラグインという名前での機能拡張が提供されている場合が多くあります。

そういえば、以前オープンソースのOCLツールというのを使ったことがあります。メタモデルを表すクラス図をテキストで書きましたが、OCLの良い勉強になりました。

最後に、皆さんの職場環境にも依存しますが、機能と同時に価格も重要ですよね。

メタモデリングについて

日本語版のWikipediaによると、「メタモデル（Metamodel）とは、所定の問題領域でのモデリングに適用可能で有益なフレーム/規則/制限/モデル/理論を意味する。メタモデリング（Metamodeling）とは、メタモデルの分析/構築/開発を意味する。この用語はメタとモデルという用語の組み合わせである。」（リンクはこちら）とあります。

IT業界の関係者の方であれば、eclipseのEMFをご存知の方も多いと思います。このオープンソースツールでメタモデルを作成する事が出来ます。何しろEMFが実装しているのはOMGのメタメタモデル標準であるMOFの基本部分ですから、EMFを使って描けるモデルはメタモデルになるという訳です。そしてそのメタモデルに基づくモデルエディタを生成することが出来ます。この部分については、当初（現在でも可能ですが）GEFというグラフィカル面を定義するツールと併せて用いることになっており、慣れた方以外使うのが難しい状況でした。現在ではこのあたりを改善したGMFを利用出来るようになっています。

EMF/GMFで作成するメタモデルはダイアグラムを意識したものになります。例えば、ネットワーク図というものがあります。ノード（クライアントやサーバのマシン）がリンク（通信路：ケーブルやワイヤレスのLAN/WANでの接続）により結ばれている図で、四角い箱が実践や点線で結ばれている図です。このメタモデルを考えると、その主要要素はノードとリンクの二つで、リンクはノードとノードの間を結ぶという関連を持ちます。そしてモデルは図ですので、ノードとリンクを含む親の役を果たすメタモデル要素（ネットワーク図）も追加します。これらにより構成されるUMLのクラス図を想定してもらうと、それがネットワーク図のメタモデルになります。EMFで作成する場合はXML文書の操作になり、GMFの場合はグラフィカルな操作になります。

OMGのホームページから公開されている標準仕様を調べるといくつものメタモデル標準が出てきます。

個人的に気がかりなのは、メタモデルが独立している（重なり合いがない）うちは良いと思いますが、重なり合いが出てきた場合に、将来的に複数のメタモデルを同時に扱うと（重なって現れるメタモデル要素について）どのメタモデルに属する要素なのか区別つかなくなるのではないか、という点です。これが名称空間などで区別出来たとしても、名前が同じだが少し意味の違うメタモデル要素を同じモデルの中でどう扱うかという問題もあります。Ontologyなんて使うのでしょうか？

上でネットワーク図の話を例にあげましたが、ちょっとご存知のアーキテクチャ図というものを思い起こしてください。多分、ほとんどのものが箱形図形要素と線の組み合わせで出来ていたのではないでしょうか？箱形図形がネストしていたり凸凹していたりというバリエーションはあると思いますが。そうすると例であげたメタモデルはアーキテクチャ図のメタモデルのベースになる要素があります。違いが、例えば箱の種類や構造、線の種類だけだとすると、上のメタモデルの箱の部分にサブクラスとして異なる種類の箱を追加するといったカスタマイズをすればかなり良い線まで近づけそうです。興味のある方は試してみてください。ただ、振る舞いの要素を表現しようとするとこれでは不充分で、ステートマシン・状態遷移図やシーケンス図・アクティビティ図に対応するようなものも必要になってくると思います。

ビジネスモデリングについて

ビジネスモデリングという正式の言葉は無いのかもしれません。ただ、昨今ビジネスとITの融合といった言葉を聞くように、企業の経営者層や管理者層少なくとも利用者のニーズと、提供されたITシステムとの間に乖離があるという話は以前からありました。このギャップを埋めるために、トップダウンとボトムアップの両方の観点から、ビジネスの世界のモデル化というアプローチが出たのではないかと思います。でもビジネスって何？という声が出てきそうです。

OMGにBusiness Modeling and Integration (BMI)というグループがあり、ここで各種の標準を開発しています。例えば、ビジネスモチベーションモデル（BMM）、ビジネスプロセス管理記法（BPMN）、ビジネスルール関連標準（SBVR）、組織構造に関する標準、などです。詳しい内容はOMGのホームページから探してみてください。

私の勝手な解釈ですが、BMMを使ってビジネスの動機・目的を明確にしそれを実現方式としてのビジネスプロセスと関連づけ、BPMNを使ってビジネスプロセスをユーザレベルで詳細記述し、またSBVRを使ってビジネスルールを記述し、その結果をサービスシステム（SOAのSです）やインフラから実現するというのが標準化活動を進めている人の持っている実現イメージのようです。SOAについてはSOAモデリング用UML Profileがもうすぐ出てきますので、それを活用することになるでしょう。このビジネスプロセスとサービスの対応付けは、ビジネスや技術環境の変化が激しい現代において、俊敏・機敏なエンタプライズを実現するのに有効なやり方だと言われています。つまり、ビジネス環境の変化に対応してビジネス戦略を見直し、それをビジネスプロセス改訂に結びつけ、最後にビジネスプロセスを実現するサービスを選び直して（改訂もあるでしょうが、別のサービスに乗り換えるというのも選択肢）組み直すようにすると短時間での対応が可能になるということです。

モデリングをしていると、何故そんな事が必要なのか、と聞かれることがあると思います。モデリングの結果を企業の資産としてとらえ、それを基にして次の戦略を考え実行するような仕組みを考えて貰いたいものです。多分、この辺りの説明が難しいのでしょう。初期投資がかかりますから。作ったモデルに基づく簡単なシミュレーションが出来れば多少改善出来ないでしょうか？

取り敢えずこのポストの結論としては、BMM – BPMN & SBVR – SOAというコンビネーションは期待が持てる、ということになります。