アーカイブ

Archive for the ‘データモデリング’ Category

BPMN 2.0 異種ベンダー間モデル交換ソリューションが続々とライナップ

2014年3月22日 コメントをどうぞ

BPMN 2.0 標準規格が発行されてから、はや2年経ちました。各BPMツールベンダーはその間、同2.0バーションの仕様に基いたモデル交換ソリューションの開発を行ってきましたが、やっと彼らのBPMソリューションとして実演ができる状況になったようです。

BPMN Model Interchange(XMLによるモデル交換) のライブデモが bpmNEXTOMG technical meeting の2つのイベント期間中、同時に行われます。このイベントはOMG BPMN Model Interchange Working Group (BPMN MIWG) のDenis Gagne氏が主催者となり、多くのBPMNベースのツールとプラットフォームの実演が行われます。

このライブデモの参加企業は次の通りです。

◾Blueworks Live from IBM
◾Bonita BPM Studio Community Edition from Bonitasoft (Open Source)
◾Oracle BPM Suite from Oracle
◾Process Modeler for Microsoft Visio from itp-commerce
◾ADONIS from BOC Group
◾camunda Modeler and camunda-bpmn.js from camunda (Open Source)
◾Signavio Process Editor from Signavio
◾W4 BPMN+ from W4 Software
◾Yaoqiang BPMN Editor from Yaoqiang
◾Activiti Designer from Alfresco (Open Source)
◾BPMN Visio Modeler and BPMN Web Modeler from Trisotech
◾With the participation of BPM.com
◾and the participation of KnowProcess.com

bpmNEXT
開催期間: 2014年3月25日-27日
モデル交換デモ: 2014年3月26日 11:00 (PT:太平洋時間) YouTube放映
場所: Asilomar Conference Grounds
800 Asilomar Ave, Pacific Grove, CA 93950, United States

OMG technical meeting
開催期間: 2014年3月24日-28日
モデル交換デモ: 2014年3月26日 14:00 (ET:ヨーロッパ時間) YouTube放映
場所: Hyatt Regency Reston
Lake Thoreau room (2nd floor)
1800 Presidents Street, Reston, VA 20190

日本国内でもすぐ利用可能
現在、上記のソリューションのうち、Bonita BPMProcess Modeler for Microsoft Visioの2製品が、下図のコンセプトに基づき完全日本語版で利用可能な状況になっています。

ビジネスプロセス管理サイクル

プロセス管理サイクル

この図は、BPMN Model Interchange(XMLによるモデル交換)の技術を活用し、上流のプロセス可視化から、下流のBPMツールの用いたプロセスの自動化とオペレーションまで、一連のビジネスプロセス管理サイクルが異種ベンダーツール間で可能になった一例です。

参照日本語情報:
Bonita BPM:オープンソースBPMジャパン株式会社
Process Modeler for Microsoft Visio:itp commerce 日本語サイト
BPMN Model Interchange(XMLによるモデル交換) :BPMNメッソド&スタイル(BPMNモデリング実践書)

広告

ブルース・シルバー著「BPMNメソッド&スタイル」日本語版、アマゾンで予約開始

2013年8月29日 コメントをどうぞ

ここ数ヶ月、本書の翻訳/監修を行っていましたが、ようやくアマゾンから販売できる状況となりましたので、お知らせします。

本書は、BPMNでビジネスプロセスをモデリングする業務コンサルタント、BPMアプリケーションの設計者、および開発者の必読書です。
英語、ドイツ語、フランス語、スペイン語に続き、ようやく日本でもBPMNの実践書が入手可能となりました。

詳細は、以下のイメージをクリックしてください。

カバーイメージ

経済産業省、「業務モデリングを中核とした手法調査研究」の第2段、公募開始

2012年10月6日 コメントをどうぞ

昨年11月に本ブログで紹介した平成23年度「電子経済産業省推進費(業務最適化のための業務モデリングに関する調査研究)」に引き続き、

本年9月14日付で商務情報政策局情報政策課から
平成24年度電子経済産業省構築事業(業務モデリングを中核とした業務最適化手法のための調査研究)
の公募が公告された。

昨年は、今から9年前の平成15年に公表された「EA策定ガイドラインVer.1.1」で策定した政策・業務体系の業務プロセス可視化方法論に世界各国で標準になりつつある新しい業務モデリング手法であるBPMNを組み込むための検証が主だった。今回は。この調査研究をベースに新EAガイドラインの策定するらしい。

事業内容は、米国国防総省のBEA9.0、DoDAF2.0等、海外の最新アーキテクチャ、昨年度の調査報告書、現行の業務・システム最適化指針、EA策定ガイドラインを参考にガイドラインを次のステップで作成することとしている。

1.新EAガイドラインの策定
2.新EAガイドラインをベースにした実務ガイドの修正
3.新EAガイドライン等の適応可能性の検証
4.検証委員会の実施

特に注目すべき実施内容は、

①業務改革目標
・最適化対象となる業務・サービスを明確にし、最適化目標実現のためのプロセスと期待される評価指標(KGI、KPI)を明確にする。
・最新のIT投資管理手法、業績測定参照モデル(PRM)等を参考に評価指標の策定手順を整理する。
②業務分析手法、業務体系
・BPMNをベースとした業務分析の手順を整理する。
・業務プロセスのモデリングに当たり、使用する記号等を決定し、記述ルールを明確にする。
・新しい業務分析・開発手法は、アジャイル開発的要素を含むこと。
③データ体系
・業務プロセスで取り扱うデータ構造を明確にするための手順を整理する。
・NIEM(National Information Exchange Model)など標準的な情報交換基盤に対応できるデータ体系と整合性の取れる記述として整理を行う

の3点である。

米国国防総省のBEA9.0、DoDAF2.0では、既に業務プロセス可視化手法としてBPMN 2.0が組み込まれたEAフレームワークが完成しており、ガイドラインを適用した業務モデルもBEA(Business Enerprise Architecture)のWebサイト上(閲覧: IE ✕, Chrome ◯)で公開されている。

BPMN 2.0 事例は、OV-6c Business Process Model のインデックスにあるそれぞれのモデルを参照(参照にはJavaアプレットのアドインが必要)。

実施内容のうち、③データ体系の「業務プロセスで取り扱うデータ構造を明確にするための手順」、および「NIEM(National Information Exchange Model)など標準的な情報交換基盤に対応(XML文書のタグ、データ型の標準化)」は、米国国防総省のDoDAF2.0でも未だ完成に至っていない最新の取り組みである。

この調査研究期間は、本年10月~来年2月としており、大きな成果が生まれることを期待したい。

詳細は、仕様書(PDF形式:206KB)PDFファイル を参照。

BPMN 2.0 ビジネス・プロセス・モデリングの解説をThink ITで連載

2010年9月3日 コメントをどうぞ

『Think IT』 / 2010年9月「限界を超える開発手法」特集で
ソフトウエア開発者に向けて、BPMN 2.0を中核にモデル駆動型開発の現状と
最新動向を解説することになりなした。

2010年9月3日から順次(全4回連載)公開します。

第1回公開: 2010年9月03日 BPM/SOAの設計・実装アプローチ
http://thinkit.co.jp/story/2010/09/03/1741
第2回公開: 2010年9月10日 BPMN 2.0の概要とビジネス・プロセス・モデリング
http://thinkit.co.jp/story/2010/09/10/1757
第3回公開: 2010年9月17日 BPMN 2.0エンジンと各社BPMツールの実装
http://thinkit.co.jp/story/2010/09/17/1762
第4回公開: 2010年9月24日 ビジネス・プロセス・モデリングの最新動向
http://thinkit.co.jp/story/2010/09/24/1771

Modeling Forum 2009のセッションビデオ公開

2009年12月1日 コメントをどうぞ

事情があって2ヶ月ほど、当ブログへの書き込みをお休みしていました。12月より発信活動を再開したいと思います。

古くて申し訳ありませんが、去る9月18日に開催されたモデリングフォーラムのストリームビデオ(ここをクリック)が公開されています。

私の講演テーマ:「BPMN 2.0に見るプロセスモデリングとデータモデリングの接点」(40分)も視聴可能です。

当日は、会場220席が満席になり当テーマの関心の高さが実感できました。

岩田

BPMN 2.0に見るプロセスモデリングとデータモデリングの接点

2009年6月17日 コメントをどうぞ

DOAを推進して来た方々は、BPMNのビジネスプロセスモデルは、「ビジネスプロセス上で取り扱われる入出力データとその相互関係が記述できない、可視化できない」という素朴な疑問を持っておられるだろう。確かにBPMN 1.2までの仕様では、データの記述仕様が曖昧なため、データの視点でプロセスをトレースするには大きな課題があった。データモデリング畑を20数年間歩んできた私自身も、ビジネスプロセスの自動化に即したデータ設計標準を待ち望んでいた。しかし、BPMN 2.0の改訂案ではこの問題点が大幅に改善されており、プロセスで取り扱うデータ仕様の記述標準化の方向性が見えてきた。今回は、BPMN 2.0で考えられているデータ仕様記述について紹介したい。

W3CのXML Schemaをデータ構造の定義標準に取り込む

BPMN 2.0では、画面、帳票などの入出力データ、サービス呼び出し時の入出力メッセージなど、ありとあらゆるデータ関連対象オブジェクトにW3CのXML Schema(以下XMLスキーマという)で定義したデータ構造にマッピング(関連付け)する方式をデフォルトで採用した。XMLスキーマは、もはやWebアプリ開発では当たり前に使われつつあるデータ構造定義言語である。

データ構造を部品として取り扱う

入出力データ、サービスの入出力メッセージなどのデータ項目は、ItemDefinition(項目定義)を通じXMLスキーマを外部参照する方法が採られている。この方法によって、データ構造の部品化と再利用、プロセスからの独立性が保持されることになる。これは従来のCOBOLコピー句やC言語のデータ構造体のincludeに匹敵する概念である。XMLスキーマをマッピングする基本構成は次の通りであり、図1にそのクラス図を示す。


ItemDefinition
 

図1: ItemDefinitionのクラス図

  1. ItemDefinition(項目定義)でデータ構造を定義する。ItemDefinitionは入出力データ、サービスの入出力メッセージなどの共通の定義形式である。
  2. ItemDefinitionは、

    ① itemKind(データ項目が物理レベル(physical)か概念レベル(information)かの識別)、

    ② structure(データ構造)、ここにXMLスキーマで定義したデータ構造要素名を指定する、

    ③ isCollection(データ構造がコレクションデータ型か否かの識別)

    の3構成要素から成る。
  3. そのItemDefinitionに関連したimportクラスのlocationでstructureで指定したデータ構造定義ファイルの格納場所を指定する。
  4. importクラスのimportTypeは、structure(データ構造)の定義形式を示し、デフォルトはXMLスキーマである。たとえば、データオブジェクトがデータベースの場合は、importTypeを「その他」に変え、ER図または、UMLのクラス図とそのファイル格納場所をstructureとlocationに指定することも可能である。
  5. あらゆるデータ関連対象オブジェクトのデータ項目は、このItemDefinitionの形式で定義される。

データを表現する新たな図形要素

BPMN 2.0では、サービスの入出力メッセージに関するデータを独立したコンポーネットで定義できるよう「メッセージ」という封書型の図形要素を新設した。また、データベースの表現には筒型のHDD記号を追加表記(定義内容は従来のデータオブジェクトと変わりない)した。これによって、データに関連するオブジェクトは、①画面、帳票などの入出力データ、②サービス呼び出し時の入出力メッセージ、③データベースの3っの表記図形となり、プロセス図上での識別もしやすくなった。また、先のデータ構造もこれらの対象オブジェクトを意識して定義することになる。図2は、BPMN 2.0で表現したプロセスフローの例である。この例では、サービスの入出力メッセージの「商品仕様」、「在庫状況」は封書型で表現しメッセージフローと点線で関連付けをしている。

 
DataMapping


図2: BPMN 2.0のプロセスフロー例

XMLスキーマの利用実態

XMLスキーマは、電子フォームの設計ツールやWebサービスのWSDLなどに使用されているが、その実態はソフトウエア開発者がプログラミング言語の延長線で利用しているに過ぎない。実際、いくつかの利用例を見てみると必要なデータ項目を1次元的にリストしているだけでデータの親子関係、型を定義するデータ構造の記述はあまり見受けられない。また、その都度、プログラミングの必要性に応じて場当たり的にXMLスキーマが生産されている場合が多く、プログラムコードの一部として扱われている。データ定義をプログラムコードから分離独立させ、部品化、再利用、統一化のためにXMLスキーマを開発しているとはとても思えないのである。この背景には、①設計者はXMLの記述を得意としない、②XMLスキーマがデータ仕様記述言語と見なされていない、③DOAの概念が入出力トランザクションの設計に活かされていない、などがある。私自身も「エディタを使ってスクラッチ状態からXMLスキーマを書け!」と言われても手が動かないのが実際である。

XMLスキーマのビジュアル設計環境とデータ構造記述能力を検証する

そこで、自己体験からビジュアルなデータモデリングツールの経験者なら習得しやすく、XMLスキーマをデータ構造定義書として活用できる方法を紹介する。まず、次の2っのツールをダウンロードし、ERwinのデータモデルがXMLスキーマにどのように変換されるかLiquid XML StudioとERwinで比較しながら両モデルの内容を確認することが手っ取り早い。この実験を通してXMLスキーマがデータ構造記述能力が高いことが分かる。

  1. Liquid XML Studio 2009 30日評価版 のダウンロード

    この製品はXMLスキーマをデータモデリング感覚でビジュアルデザインできる優れものである。ライセンスも$259/1ユーザーで求めやすい価格になっている。英語版であるが日本語処理はまったく問題ない。このツールならXMLの記述を得意としない設計者でも使えると考える。ドラック&ドロップによる要素の移動、ビジアルなダイアグラムとテキストエディタの連動、リファクタリング機能の装備、高いドキュメンテーション能力などXMLスキーマ専用エディタとしてはお奨めツールである。ただし国内販売していないのでネットで購入のこと。
  2. CA ERwin Data Modeler r7.2 30日評価版 のダウンロード

    最新のr7.2ではデータモデルをXMLスキーマにエクスポートしたり、その逆にXMLスキーマをインポートしてデータモデルを作成することが可能である。

XMLスキーマのデータ記述能力を確かめるには、ERwinのサンプルデータモデル「ビデオレンタルショップ」の論理モデルをXMLスキーマにエクスポートしてLiquid XML Studioでそのファイルを開くとER図上のデータ構造がXMLスキーマではどのように表現されるか比較しながら確認できる。


movie
 

図3: XMLスキーマ作成の元図(ERwin Data ModelerのサンプルER図)

Liquid XML Studioで読み込んだXMLスキーマのダイアグラムを図4に示す。ERwinのサンプル論理モデル内のスーパータイプ/サブタイプの汎化階層やmany-to-manyのリレーションシップもXMLスキーマのデータ構造にちゃんと反映しているのである。


XMLStudio


図4: Liquid XML Studioで編集中のXMLスキーマ

XMLスキーマファイルにエクスポートしたER図を再度ERwinにインポートすると主キー、外部キー情報は失われるが(XMLではこの情報は不要なので当然である)親子関係やカーディナリティは維持されていることが分かる。


ImportExportXML
 

図5: ER図とXMLスキーマの連携

さらに、このXMLスキーマが電子フォームの設計にどのような利用効果があるか試してみることもお奨めしたい。Microsoft Officeに付属のInfoPathをお持ちの方なら、このXMLスキーマを基にフォームデザインが可能である。複数のテーブル関係を持つデータ構造がそのままフォームデザインに継承できる方式はXMLスキーマがデータ設計書の一部として使える意義を示している。

 
InfoPath


図6: Microsoft Office InfoPathでXMLスキーマをデータソースにフォームをデザインする

ビジネスプロセスの実装にはDOAの概念が必要

ビジネスプロセスの自動化とは、「適切な人、またはシステムからデータを取得し、適切な人、またはシステムに取得したデータを配信し、適切な人、またはシステムに適切な判断を仰ぐメカニズム」をプロセスモデリングによって決定したプロセスフローの順序性に従って構築することであり、フローを流れるデータの収集、加工、配信に関わる設計作業が実装段階の中核になる(図7を参照)。これまでDOAはデータベース設計手法、方法論として扱われて来たがBPMSの世界では、データ設計の視点が画面、帳票の入出力トランザクション、サービスの入出力メッセージなど「データベース格納外データ」に移ると考えている。サービス開発ではデータベース設計が重要な役割を演じているが、サービスを利用、組み立てる側からすれば、サービスの背後のあるデータベースはどうでも良く、サービスの入出力メッセージにフォーカスすることになる。

 
7


図7: ビジネスプロセスが扱うデータ

見えてきたDOAの活かし方

図8は、私が以前から考えたいたデータモデリング対象の移り変わりを絵にしていたものである。BPMSではノンプログラミング指向の開発パラダイムであるため取り扱うデータの分析と設計を疎かにするとガベージイン・ガベージアウト(ゴミの仕様を投入すればゴミの成果物しか生産されない)の結果になりかねない。つまり、実装設計は手を抜けない仕事なのである。では、どんな方法でプロセス上のデータを設計し管理して行けば良いのか私には重要な関心事であった。OMGが標準的なデータ定義言語にXMLスキーマを選択したことは、図8に示すSPAC3層スキーマでいう外部スキーマ(データベース格納外データと私は言っている)にXMLスキーマを使うのだと解釈しており、データモデリングに関するの明快な方向性が打ち出されたと考えている。

理想的に考えれば企業全体を見渡したデータ俯瞰図を「概念データモデル」として可視化し、外部スキーマの設計内容を統制して行く姿が思いつく。この分野でのDOA適用はスタートラインについたばかりであり、今後、実践的な論議が盛んになることを期待したい。


8
  

図8: データモデリング進化・発展の系譜

岩田

BPMN 2.0仕様での記述(参考付録)

最後にデータに関わる詳細仕様と考え方については、BPMN 2.0 提案原稿の一節を引用し日本語訳をしたのでご覧いただきたい。

<引用部1>

10.3. データ項目

プロセスモデリングには、従来からプロセス実行中に作成、操作、参照するデータ項目(物理的あるは概念レベルの項目)をモデル化できることにが求められている。ここで重要な点は、データの構造を捉え、その構造に対しクエリーや操作ができるかである。

BPMNそれ自身は、データ構造を記述するモデルやデータをクエリーするための式言語を組み込んで提供していない。その代り、外部で定義したデータ構造と式言語を結びつけるフック(hook)を形式化している。さらに、その同一モデル内で複数のデータ構造と式言語の共存を許している。これらの言語の互換性と検証は本仕様の範囲外であり、ツールベンダーの責任になる。

BPMNは、そのデータ構造記述言語としてXMLスキーマを、式言語としてXPathを指定している。しかし、ベンダーは彼らの独自言語でそれらを代用することは自由である。

10.3.1. データモデリング

プロセスモデリングには、従来からプロセス実行中に作成、操作、参照するデータ項目(物理的あるは概念レベルの項目)をモデル化できることにが求められている。

BPMNでは、Data Objects,
ItemDefinition,
Properties,
Data Inputs,
Data Outputs, Messages,
Input Sets,
Output Sets, and Data Associationsなど(非斜体は図形要素、斜体は要素属性を示す)、さまざまな構成要素を通じてこの要求を実現している。

<中略>

つぎに特定のアクティビティ実装時のデータ入力およびデータ出力の関連付けについて述べる。

サービス・タスクでのデータ関連付け

操作(operation)のInMesseageRef属性で参照しているメッセージ(Message)定義にはそれに関連付けられた項目定義(ItemDefinition)を持つデータ入力(Data Input)がひとつ存在する。この操作が出力のメッセージを定義している場合は、操作(operation)のOutMesseageRef属性で参照しているメッセージ定義にはそれに関連付けられた項目定義(ItemDefinition)を持つデータ出力(Data Output)がひとつ存在する。

ユーザー・タスクでのデータ関連付け

ユーザータスクは、データ入力(Data Input)、データ出力(Data Output)、ユーザータスク範囲で利用可能なデータアウェア要素(data aware elements)へのアクセスを持つ。

呼び出しアクティビティでのデータ関連付け

呼び出しアクティビティは、呼び出し可能要素(callable element)で応答を返すので、呼び出しアクティビティのデータ入力および出力は、呼び出し可能要素(callable element)で定義したデータ入力(data input)、入力セット(inputset)およびデータ出力(data output)、出力セット(outputset)と合致していなければならない。呼び出しアクティビティのデータ入力およびデータ出力は、排他的なデータ関連がなければ、呼び出し可能要素(callable element)の対応するデータ入力およびデータ出力にマップされる。

スクリプト・タスクでのデータ関連付け

スクリプト・タスクは、データ入力(Data Input)、データ出力(Data Output)、スクリプトタスク範囲で利用可能なデータアウェア要素(data aware elements)へのアクセスを持つ。

【原文】


10.3. Items and Data

A traditional requirement of Process modeling is to be able to model the items (physical or information items) that are created, manipulated, and used during the execution of a Process. An import aspect of this is the ability to capture the structure of that data and to query or manipulate that structure.

BPMN does not itself provide a built-in model for describing structure of data or an expression language for querying that data. Instead it formalizes hooks that allow for externally defined data structures and expression languages. In addition, BPMN allows for the co-existence of multiple data structure and expression languages

within the same model. The compatibility and verification of these languages is outside the scope of this specification and becomes the responsibility of the tool vendor.

BPMN designates XML Schema and XPath as its default data structure and expression languages respectively, but vendors are free to substitute their own languages.

10.3.1. Data Modeling

A traditional requirement of Process modeling is to be able to model the items (physical or information items) that are created, manipulated, and used during the execution of a Process.

This requirement is realized in BPMN through various constructs: Data Objects,
ItemDefinition,
Properties,
Data Inputs,
Data Outputs, Messages,
Input Sets,
Output Sets, and Data Associations.

The following describes the mapping of data inputs and outputs to the specific Activity implementations:

Service Task Mapping

There is a single data input that has a ItemDefinition equivalent to the one defined by the Message referred by the inMessageRef attribute of the operation. In the case the operation defines output Messages, there is a single data output that has an ItemDefinition equivalent to the one defined by Message referred by the outMessageRef attribute of the operation.

User Task Mapping

User Tasks have access to the Data Input, Data Output and the data aware elements available in the scope of the User Task.

Call Activity Mapping

Since Call Activities rely in the callable element being invoked, the data inputs and outputs of the Call Activity must match with the data inputs, inputsets and outputs, outputsets defined in the callable element. The data inputs and outputs of the Call Activity are mapped to the corresponding data inputs and output of the Callable Element without any explicit data association.

Script Task Mapping

Script Tasks have access to the Data Input, Data Output and the data aware elements available in the scope of the Script Task.

<引用部2>

8.3.12. 項目定義(ItemDefinition)

データオブジェクトとメッセージなどのBPMN要素は、プロセスフロー上で操作、転送、変換、蓄積されるデータ項目を表現する。これらの項目は、自動車の機械部品のような物理的なデータ項目(physical)か、 自動車の機械部品カタログのような抽象的な情報項目(information)のいずれかにすることができる。プロセスにおけるデータ項目の重要事項は、それらの構造である。BPMNはこのデータ構造を記述する特別なフォーマットを要求しないが、デフォルトとしてXMLスキーマを指定している。この構造属性は実際のデータ構造を参照する。すべての要素に対するデータ構造のデフォルトフォーマットは、その定義要素内にあるtypeLanguage属性を使って指定される。たとえば、このtypeLanguageの値が”http://www.w3.org/2001/XMLSchema” であれば、定義内の要素はXMLスキーマの形式でデータ構造を示している。typeLanguage属性が未指定ならば、XMLスキーマがデフォルトである。Importはデータ構造の場所を特定するために使用される。たとえば、XMLスキーマで記述されたデータ構造がある場合、Importはそのスキーマのファイル保管場所の指定に使われる。構造定義は、常に分離実体として定義されるので、利用するプロセス記述内にインライン化はできない。 <以下省略>

【原文】


8.3.12. Item Definition

BPMN elements, such as DataObjects and Messages, represent items that are manipulated, transferred, transformed or stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle. An important characteristics of items in Process is their structure. BPMN does not require a particular format for this data structure, but it does designate XML Schema as its default. The structure attribute references the actual data structure. The default format of the data structure for all elements can be specified in the Definitions element using the typeLanguage attribute. For example, a typeLanguage value of http://www.w3.org/2001/XMLSchema” indicates that the data structures using by elements within that Definitions are in the form of XML Schema types. If unspecified, the default is XML schema. An Import is used to further identify the location of the data structure (if applicable). For example, in the case of data structures contributed by an XML schema, an Import would be used to specify the file location of that schema.

Structure definitions are always defined as separate entities, so they cannot be inlined in one of their usages.

見えてきたBPMN 2.0の全貌

2009年5月14日 コメントをどうぞ

OMGが開発を進めているBPMN 2.0標準仕様の採択が本年6月に行われる予定である。その詳細は明らかにされていなかったが、あるWebサイト(ここのページからダウンロード可)に2009年5月11日付けの最新「BPMN 2.0 提案原稿」が公開されていたので改訂ポイントを紹介したい。この仕様書はA4にして487ページと膨大なため精読は不可能に近い。以下に私の興味あるポイントだけを示す。

BPMNの命名変更

これまではBPMNというと
Business Process Modeling Notationの略称であったが、 2.0からは
Business Process Model and Notationに名称が変更されている。

4っの適合基準

新仕様ではConformance(適合or適合性)という語彙が盛んに使われており、本仕様を活用する場面/目的を次の4っの領域に分けBPMNの仕様準拠基準を規定している。(詳細はPage 27 2.Conformanceを参照)

  1. Process Modeling Conformance (ビジネスアナリストがプロセスデザインする領域)
  2. Process Execution Conformance (ITスペシャリストが実行可能なモデルをデザインする領域)
  3. BPEL Process Execution Conformance (BPMN vs. WS-BPELマッピング仕様)
  4. Choreography Modeling Conformance (2.0で新たに加わったコラボレーションプロセスのコレオグラフィーの可視化)

たとえば、BPMNのプロセス図には、プロセスタイプ(ProcessType)というプロパティが設けられ、1の適合モデルか、 2の適合モデルか、その値が”non-executable”か、”executable”かで識別できるようにしている。

この適合基準を設けた背景には、

  • プロセス実行に必要な可視化表現の追加、実行可能設計属性(実行セマンティックス)の追加、不完全であったBPMN- BPEL変換仕様の強化など、仕様改訂が「ITスペシャリストがBPMNを使って実行プロセスモデルを設計可能する(実行可能設計)」 に力点が置かれたため、表記図形要素と定義属性がBPMN1.xに比して増加し複雑かつ難解になった(この作業はIBM、Oracle、 SAPが中心になって進められたようだ)。
  • そのため、BPMN仕様の利用範囲がビジネスプロセス分析からIT実装まで幅広くなり、用途別に適用範囲を定める必要が生じた。 特にビジネスアナリストグループからは、1と2の境界を仕様で示してほしい声が上がった。
  • ベンダーがBPMN準拠製品を開発する際の準拠基準とツール間の相互運用性保証ガイドラインが必要となった。

などがある。いずれにせよ、仕様適合基準が設けられたことは大きな前進である。

大幅に増えたイベント表記図形

仕様書Page 256の「Table 10-91 Types of Events and their Markers」にすべてのイベント表記図形が列挙されている。この表の行方向に示されるイベントタイプでは、EscalationとParallel Multipleが新たに加わった。さらに列方向に示される配置場所では、開始イベント、中間イベントにそれぞれ”Interrupting”、” Non-Interrupting”が加わり、図形のバリエーションが大幅に増えている。この図形の多さには、「こんなに必要なのか?」と面食らう。IBM、Oracle、SAP連合が参画しているのだから、これらのバリエーションとセマンティックスはちゃんとWS-BPELにマッピングできるのだろうと勝手に想像している。

Table 10-91 Types of Events and their Markers


event

アクティビティ・タスクタイプの追加とアイコン統一

ビジネスルールに基づいて判定するデシジョンサービスのタスクタイプが新たに追加され、ベンダ製品ごとに異なったタスクタイプのアイコンも仕様に明記され統一化された。


TaskType

ビジネスルールエンジンを使ってWebサービス経由で意思決定を自動化するBRMSの考え方がビジネスプロセスモデルに取り入れられている。

新たに加わったコレオグラフィーの表記

2.0でのハイライトのひとつは、企業間コラボレーションプロセスでメッセージのやり取りの実行手順を可視化したコレオグラフィーのサポートである。コレオグラフィーは複数のサービスを連携させた、複雑なWebサービス間のプロセスフローを可視化し複数のオペレーションの依存関係や実行順序などを記述するためのものである。 BPMN1.xではプールとメッセージフローを使用してコラボレーションプロセスを表記できたが、より詳細なメッセージングの実行順序は表記できなかった。仕様書Page 256の「Figure 9-7 An example of a Choreography within a Collaboration」にコラボレーションプロセスにコレオグラフィーを追記した例図があり参考にされたい。

仕様書Page 64の「Figure 7-7 An example of a stand-alone Choreography diagram」は、コレオグラフィー部だけを独立して表記したコレオグラフィー図の例である。状況依存で実行順序が制御されることがこの図から分かる。

Figure 9-7 An example of a Choreography within a Collaboration


coreo

Figure 7-7 An example of a stand-alone Choreography diagram


coreo2

カンバセーション図

プールとメッセージフローを使用して表記したコラボレーションプロセスを抽象化し、ステークフォルダー間の関係を図示するカンバセーション図の表記が新たに加わった。仕様書Page 316の「Figure 11-3 Conversation diagram depicting several conversations between Participants in a related domain」にカンバセーション図の代表例が示されている。この図は、ビジネスアナリストがビジネスプロセスモデルの外観図としてステークフォルダー間の関係を図示するために使用するものと思われる。

Figure 11-3 Conversation diagram depicting several conversations between Participants in a related domain


conversation

BPMNとWS-BPELのマッピング

仕様書Page 432にこのマッピング仕様が記述されている。 BPMNで表記した図形要素やプロセスパターンがどのようにWS-BPELに変換されるか確認できる。

仕様書Page 455の「15.2. Extended BPMN-BPEL Mapping」では、 WS-BPELがブロック構造記述であるがゆえに簡単にはマッピングできない問題箇所(特にループバック)に焦点をあて、解決策を提示している。 BPMNとWS-BPELのマッピングをサポートするツールベンダはこの箇所の問題解決を図らなければならないのである。

所感:

BPMN 2.0では、BPMNを使って「実行可能設計(Executable Design)」を実現する狙いがあると考える。これまでのBPMN 1.xはビジネスアナリストグループやBPMベンダで構成するBPMI.orgで策定された。BPMN 2.0は、IBM、Oracle、 SAPなど、ITベンダが主導するOMGに受け継がれ、IT寄りの仕様強化が中心になっている。その結果、ビジネスからITへ実行の道筋(the pathway to execution)が具体的になってきた半面、IT寄りの仕様が膨らんだため、BPMN 1.xに慣れ親しんだ利用者は、難解なイメージを持つことだろう。このイメージを払拭するにはビジネスとITの両面からそれぞれのBPMN利用範囲を限定的し利用しやすくする工夫が必要である。

仕様書には実行セマンティックス(execution semantics)という語彙が度々登場する。これまでBPEL(実行言語)しか持たないSOAベンダが実行のための設計情報をBPMNで記述する挑戦が2.0に表出している。では、BPELは不要になるのでは?との素朴な疑問が生じる。

2008年12月25日のInfoQでのBPMN 2.0 バーチャル座談会では、BPMN 2.0の策定に参加したIBM, Oracle, SAPの意見が次のように述べられている。

Q:BPMN 2.0とBPEL 2.0との関係について教えてください。BPMN 2.0によってBPELは不要になるのでしょうか?

(IBM, Dave Ings氏) これまでの説明にもありましたが、 BPMNはモデリング向けであり、BPELはデプロイ向けです。 これらはどちらもBPM開発ライフサイクルをサポートする基本的な標準です。

(Oracle, Manoj Das氏) まず、BPMNはモデリング標準であり、BPELは実行時の標準です。 その点においてどちらも補完的であり、BPMNのモデルはBPELプロセスとして実行されます。とはいえBPMN 2.0は十分な実行セマンティクスを定義していることから、実装の中にはBPMN 2.0を直接実行し、BPEL 2.0と重なるようなものも出てくるでしょう。2つのアプローチ、 すなわちBPMNモデルをBPELとして実行する方法とBPMNを直接実行する方法がより合う異なったユースケースがあるのでしょう。

(SAP, Ivana Trickovic氏) BPELはWebサービスベースのプロセスのためのモデルと実行セマンティクスを定義していますが、 これはBPMNの機能のサブセットです。たとえば、BPMNでは任意のグラフや複雑なデータフローを描くことができます。BPMN 2.0の提案にはBPMNサブセットとBPELとのオプションのマッピングを含んでいます。 これは環状にならないようなブロック構造のフローに制限しています。 これらのBPMNプロセスはBPELベースの実行環境で実行することもできます。

それぞれ、ベンダの製品戦略によって、この疑問への答えは異なっている。IBMは(WebSphereが主力製品なので)BPELは無くならないと言い、Oracleは(BPMNとBPELのハイブリッドエンジンを開発中なので)BPMNから直接実行する場合もあれば、 BPELに変換してから実行する2通りが混在すると言い、SAPは(ヒューマンセントリックプロセスに特化したNetWeaverが主力製品なので)BPMNからの直接実行が基本で、ループバックのない直線的なプロセスの一部はBPELに変換してから実行する場合がある、と言っている。

岩田