ホーム > データモデリング, プロセスモデリング, BPM, BPMN, SOA, 標準化 > BPMN 2.0に見るプロセスモデリングとデータモデリングの接点

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

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.

広告
  1. まだコメントはありません。
  1. No trackbacks yet.

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中