ソフトウェアアーキテクチャのモデル記述について

以前も触れたと思いますが、ソフトウェアアーキテクチャをWikipediaで引くと次のようなエントリが出てきます。

  1. Software architecture

ここで例としてあげられているアーキテクチャは、いわゆるエンタプライズアーキテクチャが中心で、他にRM-ODPとサービス指向モデリングが含まれています。さて、こういったアーキテクチャに基づく設計をしようとすると、そのアーキテクチャを適用したシステムモデルを書くことになります。この段階で、このブログの対象としているアーキテクチャとモデリングの間の関連付けが現れてきます。さて、どんな文書になるのでしょう?ドロー系のソフトやPowerPointを使っての単なるダイアグラムがまず考えられます。人によってはWordやExcelでダイアグラムを作成されることも有ります(かなりの技能が必要だと思います)。そしてUMLツールや専用ツールもあります。UMLツールの場合は、そのアーキテクチャ記述用のProfileやAdd-onなどが提供されていれば良いのですが、無ければ自作したり、例え高額になっても専用ツールを探すということになります。

エンタプライズアーキテクチャの場合、記法自体が標準化されていないため、いろいろなバリエーションが出てきます。少なくとも国ベースで記法の標準を定めて貰いたいし、出来れば国際標準にもして貰いたいくらいです。日本の場合には政府のイニシアティブがあり、

  1. 業務・システム最適化に関する全般的事項(PDF:257KB
  2. 業務・システム最適化企画指針(ガイドライン)(PDF:626KB
  3. 業務・システム最適化実施指針(ガイドライン)(PDF:473KB
  4. 業務・システム最適化実施の評価指針(ガイドライン)(PDF:328KB
  5. 業務・システム最適化指針(ガイドライン)(PDF:857KB

などとして公開されており、この中でも5番目のガイドラインが日本政府でのEA適用方法を具体的に書いています。これに関して、経済産業省のEAポータルにはVisioベースのツールが公開されており、またINTAPでも「日本版EA対応UML Profileに関する研究報告書」でそのUML Profileを独自規定し幾つかのUMLツール用のProfileデータを公開しています(リンク)。本家の米国FEAでも種々の活動が進められており、専用ツールのSystem Architect®や、幾つものUMLツールがDoDAFをProfileとしてサポートすることで利用されています。また方法論的なものとしてはOpenGroupのTOGAFが利用されています。

話題を政府系から他へ向けると、どうも決定版のものが見えきません。個別にアドホックで専用ツールを作成したり、やはりアドホックに近いUML Profileが使われているのかもしれないし、またはDSLが使われているのかもしれません。

まとめると、ベースとするソフトウェアアーキテクチャを決め、そのアーキテクチャに基づくシステム設計を行いそれを描画ツールやモデリングツールを使い文書化し、そういったものをベースに開発が行われているのだろうと想像できます。そうすると、名前のないアドホックツールやアドホックProfileを使い作成されたアーキテクチャ文書の運命はどうなるのでしょう。とりあえず開発に使われるでしょうが、仕様変更が多発すると徐々にメンテできなくなるのではないでしょうか。やはり、ここはシステム仕様(モデル)の貯蔵庫を作って保管し、モデルベースで仕事を進め、常時モデルのメンテも行わざるを得ない仕組みが必要になるのでしょう。

ソフトウェアアーキテクチャのモデル記述について

SOAモデリングについて(2)

これも以前のポスト関連です。SOAモデリングについてでUML Profile and Metamodel for ServicesというRFPのことを話題にしましたが、日本語版InfoQにその関連記事が掲載されています。

  1. OMG が SoaML のドラフトをリリース

この記事の「MicrosoftがSoaMLの提案メンバに入っていない」という指摘は確かにその通りですが、このRFPを作った段階、そして仕様案をまとめていた段階、いずれでもMicrosoftはOMGに未加入でしたので、「それは仕方無いでしょう」ですね。提案メンバに入っていないという事実が何らかの政治的メッセージを意味すると解釈されるなら、それはちょっと残念なことです。

この仕様案を私も昨年試作したことがあり、Profile自体は比較的簡単なものだということが分っています。しかしこれをどう使うかというのがポイントになると思います。まずはUMLツールに組み込まれる必要がありますが、現場で使い物になるまでには、分析や開発のプロセスの中のどこで何を適用するのか、BPMNで書いたビジネスプロセスとはどうつながるのか、SOA環境を提供する各種プラットフォーム(実装)にどう対応付けするのか、など試行錯誤が必要なステップを幾つか乗り越える必要がありそうです。

そうは言っても、大きな前進です。このProfileが活用されることを期待します(私ももう一度トライしてみます)。

SOAモデリングについて(2)

EAI -> SOA -> Cloud Computing?

米国のbloggerでSOAで有名なDavid Linthicum氏という方がおられます。初めてこの方の名前を知ったのは、EAI(昔は今のSOAくらい有名な言葉でした)関連のジャーナル記事でした。当時EAIの片隅を担当していましたので記憶に残った次第です。確かEAIの書籍も書かれていたはずです。しばらくは何も聞こえてこなかったのですが、次にこの方の名前と遭遇したのがSOAです。オンライン版InfoworldのReal World SOAというブログカラムとそのPodcastです。

  1. Real World SOA
  2. Real World SOA Podcast

この方は内容だけでなく話もうまいのでついついPodcastを聴くことになっていました(米語の聞き取り練習にもなります)。その彼がしばらく前からCloud ComputingのPodcastを始めています。

  1. Cloud Computing Podcast

彼の足跡をたどると、「SOAはEAIの発展形であり、Cloud ComputingはSOAの発展形だ」、ということになりそうです。すべての側面でそうは言えないと思いますが、一つの見方だと思います。セキュリティやコンプライアンス他でがちがちになった企業システムをこの方向に持ってゆくのは大変だと思いますが、そのうち向かうことになる道かもしれません。

この方以外にもSOA bloggerで有名な方々の情報を幾つか追加しておきます(他にも沢山ありますので調べてみてください)。

  1. Todd Biske氏のOutside the Box
  2. Sandy Carter氏のService Oriented Architecture (SOA) — Off the Record
  3. Dana Gartner氏のBriefingsDirect
  4. Judith Hurwitz氏のブログ
  5. Joe McKendrick氏のService Oriented
EAI -> SOA -> Cloud Computing?

Dr. Richard Soley講演会模様

以前のポストでDr. Richard Mark Soleyの講演会 in Yokohamaについてという紹介をしましたが、私も参加してきました。講演内容はOMG meetingsなどでSoleyさんがよく話しているものをベースにほんの少しアレンジした、という感じでした。下に見つけたzdnet記事のURLを掲載します。

  1. UMLとVisual Studioの連携がIT市場の進化を促す–OMG会長がtech daysで来日

一緒に聴講した知り合いの方の言葉でもありますが、講演参加者がとても多く、マイクロソフト技術を使われている開発者の方々のモデリング(MDA)への関心の高さに感心した次第です。マイクロソフト社の各種モデリング系ツール(Visual Studio DSL, Oslo他)がUMLをサポートする場合、ツール利用者である国内の開発者の皆さんがどのように異なる種類のモデルを使い分けて実装に続けられるのか、楽しみにレポートを待ちたいと思います。

なお、Soleyさんは翌日1000名を超える参加者(多数のマイクロソフト顧客を含む)にキーノート講演の一部として再度このような話をされたようです。

Dr. Richard Soley講演会模様

Event Driven Architectureについて

Event Driven Architecture(EDA:日本語だと「イベント駆動アーキテクチャ」でしょうか)というアーキテクチャスタイルがあります。例によってWikipediaを眺めてみると

  1. Event-driven architecture

というエントリが見つかります。GUI設計における入力イベント待ちループの話だけではなく、分散処理に関する文献にあたっているとイベント処理が良く現れます。そういえばCORBAでもそういうオブジェクトサービスがありました。

モデリングの分野でも、ビジネスプロセスモデリング、SOAモデリング、テレコム系のモデリングなどで出現します。なかなかメインストリームにならなかったのですが重要な要素です。個人的にはPublish and subscribeのデザインパターンになじみがありますが、上のWikipediaによるとイベント処理のスタイルには次があるそうです。

  1. Simple event processing
  2. Event Stream Processing
  3. Complex event processing

従来のものが最初のカテゴリだとすると、センサーネットやRFIDのシステムなどイベントが途切れることなく送られてくる場合を扱うのが2番目、そしてイベント間の相関に着目しアクションを取るようなものが3番目、という分類のようです。

CEPについてはこの言葉を作り出した人による次のサイトがあり、このページをみるとどのようなベンダ・製品があるか分ります。

  1. Complex Event Processing

これまでのところ金融分野などで怪しげな取引を見つけ出すといったことに使われているようですが、今日の携帯端末の普及状況を考えると、今後適用分野拡大が期待できる技術かもしれません。

Event Driven Architectureについて

Eclipse Modeling Projectについて

先日検索エンジンを使って「eclipse + モデリング」を試してみました。ヒットしたのは日本語翻訳版のEMF本に関するものがほとんどだったと思います。調べた動機は、国内でeclipseを使ったモデリングやその後のコード生成などにどの程度関心が持たれているか、ちょっと気になったためです。

eclipseはご存知のIDEですが、当初より(OMGのMOFサブセットを実装した)EMFコンポーネントを含んでおり、オープンソースとなったことに驚いたものでした。さて本家eclipseにはEMF/GMFを始めモデリング関連のプロジェクトが多くあります。そのリストは次のURLにあります。

  1. Eclipse Modeling Project

eclipseのダウンロードにあたっても、Eclipse Modeling Toolsということで主なモデリングコンポーネント(プラグイン)をまとめたものが用意されています。上のリストにある個別のプロジェクトについてそのうち話題にするかもしれません。

商用モデリングツールというのは歴史的に高価なものが多いのですが、UMLに関してはリーズナブルな価格帯のツールも存在します。それでも、とりあえず試してみたい人にとってはオープンソースは有り難い存在であり、それもeclipseベースであれば文句ありません。但しそれはあくまで「試す」段階の話で、本気で使うなら別の観点からの配慮が必要かもしれません。それでも、発展途上にあるモデリングやMDD技術についてオープンソースで試せるのは有り難いことだと思います。MDDという意味では、モデリングが開始点だとしても、途中からソフトウェアの設計・開発作業になり、実行するためのプラットフォームも必要になります。各種の開発手法・ツール、プラットフォームとしてApacheなど利用させて貰う事が可能ですし、ひょっとするとそれをCloud上で実行(?)、というところまで視野に入ってきます。

eclipseに関連して、eclipse plugin centralというサイトも有ります。ここには商用を含め多くのプラグイン更新情報が掲載されており、モデリングやUMLという分類の下に興味深いものが見つかることがあります。

さて、書店に行って眺めていても、まだeclipse+モデリングという視点からの書籍(日本語の本という意味です)は余り見当たりません(EMF本くらい?)。そのうち関心を持つ人が増えて、そういった特集記事があちこちの雑誌に現れればと思っています。

ちなみにEMF本ですが、英語版はもう第2版になっています。

Eclipse Modeling Projectについて

Domain Specific Language(DSL)について

ご存知の方もおられると思いますが、Domain Specific Language (DSL) という言葉があります。Wikipediaで調べてみると、次のエントリが見つかります。本エントリではモデリングの観点からだけDSLを考えますが、例えばRuby on RailsのRailsはRuby言語に組み込まれたDSLと言われています。

  1. ドメイン固有言語
  2. Domain-specific language

ある限定された領域(ドメイン)において有効な言語ですが、モデリングの世界でUMLのようなどちらかと言うと汎用的モデリング言語より、その時々に応じて必要な概念だけを扱うDSLの方が有効という議論があります。

UMLのUはUniversalではなくUnifiedであり、良く利用されているモデリング言語を統合したという意味になります。そうすると、必ずしも良く利用されていないモデリング言語はその外側に置かれているということになります。通常UMLは汎用モデリング言語でありDSLと認識されていませんが、OMGのAndrew Watson氏はあるインタビューで、UMLの各ダイアグラムを個別に見れば各々がその領域に特化したもの(例えばステートチャート)なのだからUMLもDSLの一種と考えられる、というようなコメントをしていました。

DSLを支援するツールにはMetaEditやGMEなどが昔からあったのですが、数年前にMicrosoft社Visual StudioのDSLツールの発表で改めて脚光を浴びたと思います。eclipse GMFもこのカテゴリです。こう書くと、DSLツールとメタモデリングツールの差が分らないと思いますが、個人的にはこれらは同じでありどこを強調するかが違っているだけと考えています。さて、これらグラフィカルツールの良いところは、利用者がドメイン固有の概念をグラフィカルに規定すれば1)その概念に基づくグラフィカルなモデルエディタが使えるようになり、2)その結果を元にある程度のコード生成なりにつなげることが出来る、ということです。

UMLよりDSLの方が良さそうに思えるかもしれませんが、結局言語を設計することになるので、最初の定義部分を確実にする必要があり、どれだけやれば大丈夫かが難しいところかもしれません。また、類似のDSLが幾つも作成されると、まずはモデルの理解、そしてそれらに基づいたモデルの交換や統合などいろいろ現実的な問題が出てきそうです。標準化や調整のようなことが必要になってくるのでしょう。良い点は、うまく設計すれば必要最低限の概念でモデルを表現できるようになることでしょうか。

これに対し、DSLに対応するようなUMLの機能としてUMLの拡張メカニズムというものがあります。この機能を利用するとUMLをベースにして新しい(ある意味)モデル言語を作ることが出来ます。これはProfileと呼ばれるものです。例えば、UML Profile for EDOCという仕様では、EDOCに現れる概念はどのようなものであり、それがどのようにUMLの各要素にマッピングされるか(ステレオタイプやタグ値など)を規定しています。その結果できることは、UMLツールにこのProfileを組み込むと、例えばクラス図で通常のクラスとは違ったステレオタイプ付きのクラスを導入することができ、それを使ってEDOCモデルが作成できるようになることです。このアプローチの場合、出来上がったモデルは本来のUMLの備えるすべてのものを継承しているため、比較の問題ですがより大きな・複雑なモデル(データ)になってしまうことです。

いろいろ書きましたが、DSLは今後も利用が広がってゆくと思います。そのうち続編を書くことになりそうです。

Domain Specific Language(DSL)について

Microsoft Oslo について

以前少し触れたことがありますが、MicrosoftのOsloが注目されています。元々VisioでUMLダイアグラムがかけたのですが、2005年頃にDSL Toolを出してからはDSL陣営(?)の先頭に立ってUMLを批判していたような気がしました。しかし、昨年Visual Studioで(DSLツールの延長線上?)UMLもサポートするような方向性を打ち出し、同時にこのOsloを発表しました。Osloはまだ完成したものでなく一種のイニシアティブのように見えますが、それでも流石はMicrosoftで幾つものツールを公開しました。Microsoft側からの情報としては

  1. “Oslo” Developer Center
  2. Videos on “Oslo”

などがあり、ここから現時点でのOsloの雰囲気が分ります。前者のページにも掲載されていますが、当ブログでPodcastとして紹介したSoftware Engineering RadioでOsloについてのエピソードが流されています。M言語の位置づけ、DSLツールとの関連、今後の展望など、外部の視点からいろいろ質問を投げかけ、それなりの回答を得ています。ちょっと長いですが、関心をお持ちの方は聴いてみる価値があると思います。インタビューの中で(本質的ではないのですが)Oslo開発チームメンバは元Smalltalkerと元LISPerの2種類に分類されると言っていた箇所が面白かったです。M言語については何らかの形でオープンなものを目指すそう(eclipseとも話をしている様子)ですので今後に期待しましょう。

Microsoft Oslo について

Ontologyについて

モデリングの世界ではUML、メタモデリング、DSLなどの話題が豊富にありますが、Ontologyというのも近い場所にいると思われます。W3Cで推進しているSemantic WebはOntologyを活用した次世代Webだと言われています。

ビジネスモデリングの世界では現在ビジネスプロセス管理が中心的な役割を果たしていますが、これと同じようなビジネスルール管理という世界があります。つまり、プロセスで整理するというより、どんな規則がありどう適用されるかという観点での整理を行おうというものです。プロセスエンジンに対応するようなルールエンジンがありルールを実行します。実際にはビジネスプロセス処理の中でビジネスルールの適用・実行を行うようなハイブリッドの形態で使われることが多そうです。

ここから本題に入ります。ビジネスルールというものはどのように記述されるでしょう?まず基本として自然言語で規則を書き下し、それを何らかの形に構造化します。詳しくは、ビジネスルールの世界の標準である Semantics of Business Vocabulary and Business Rules を参照して頂きたいのですが、どうしても言葉・概念がその要素になります。従って、そこに出てくる言葉・概念が、別の場所に書かれている言葉・概念とどういう関係にあるのか(例えば、同じなのか)ということが大きな問題となり、そこからOntologyの世界とのつながりが出てきます。

Ontologyという学問・研究は意義のあるものだと思いますが、これが実世界でどう適用されるのかという点が気になっています。上に書いたように、概念Aと概念Bが同じかということを(推論エンジンなどを使うことになると思いますが)100%の精度で言えるでしょうか?もし、AとBが70%の確立で同じであり、BとCも70%の確立で同じだとすると、AとCは49%の確立で同じ(?)ということになり、50%以下の確率のものをコンピュータ処理で使えるでしょうか?きっと何か良いアイデアがあるのだろうと思いますが、この点がOntologyを実際に使うというと気になるポイントです。

それは素人の考え方だと思われる方、正しい理解の仕方をアドバイスして頂ければ有り難いです。

ところで、Ontology関連の有名なオープンソースツールがあります。Protégé というOntology Editorです。このツールで作成出来るもの(画面例など)をみると、Ontologyで目指している方向性についてイメージが涌き易いかもしれません。

Ontologyについて

アーキテクチャについて(2)

ソフトウェアアーキテクチャ(software architecture)をWikipediaで調べてみると次のようなトピックスが含まれています。

  1. アーキテクチャ記述言語(Architecture description languages)
  2. ビュー(Views)
  3. アーキテクチャフレームワーク(Architecture frameworks)
  4. アーキテクチャスタイル/パターンの例(Examples of Architectural Styles / Patterns)

アーキテクチャ記述言語についてはWikipediaに別のエントリがあり、幾つもの事例があげられています。

ビューに関してはIEEE 1471を参照し、次のような例をあげています。

  • Functional/logic view
  • Code/module view
  • Development/structural view
  • Concurrency/process/thread view
  • Physical/deployment view
  • User action/feedback view
  • Data view

また、アーキテクチャフレームワークの例としては次をあげています。

  • 4+1
  • Department of Defense Architecture Framework (DODAF)
  • UK Ministry of Defence Architectural Framework (MODAF)
  • The Open Group Architecture Framework (TOGAF)
  • Zachman framework
  • Federal Enterprise Architecture (FEA)
  • Reference Model of Open Distributed Processing (RM-ODP)
  • Service-Oriented Modeling Framework (SOMF)

ここで言うソフトウェアアーキテクチャは、コンピュータシステムを大きく捉えた場合のアーキテクチャであり、ソフトウェアの詳細に関するアーキテクチャではありません。詳細に関してはもっと別の観点からデザインパターンなど別の世界があるということのようです。

アーキテクチャスタイルの例としては、Client Server, Event Driven Architecture, SOA, … といったものが並んでおり、かなりテクノロジ寄りのアーキテクチャというイメージです。

アーキテクチャ記述に関して、IEEE 1471がISOで標準化の道を歩んでいますが、これだけではなくアーキテクチャ記述言語についてもどこかで標準化して貰いたいものです。

アーキテクチャについて(2)