ビジネス・サービス・モデリング

WebSphere Business ModelerとRational Software Modelerの統合

ビジネス・プロセス・モデルは通常、ビジネス・ゴールと目的を達成するための、ビジネス・オペレーション上の要求事項を規定するために使われています。こうしたビジネス・プロセス・モデルは多くの場合、ワークフロー・ベースのランタイム・プラットフォームで直接実行されます。しかし場合によると、ビジネス・プロセスやビジネス・プロセスの中のタスクには、他のアーキテクチャー・ソリューションを利用した方が有利です。そうしたソリューションを利用することによって、ビジネス・サービスのプロバイダーとの統合が実現でき、あるいは再利用を促進することができます。BSM(Business Services Model)は、ビジネス要求とITソリューション・アーキテクチャーとの間のセマンティック・ギャップを埋めるものです。

BSMは各ビジネス・プロセスを契約として扱うことによって、ビジネス・プロセス・モデルと、モデルを実現するモデル要素との間の正式な関係を表現します。この契約では、サービス・プロバイダーを、コラボレーションの中でロールを果たすもの、つまり、あるビジネスの目的を達成するためのロール間の相互作用ルールとして振り付けられた責務を果たすもの、として規定します。契約によって、可能性のある多くの方法のうち何をすべきかを規定した仕様が、明確に分離されるのです。
またBSMは、IBM®のWebSphere® Business ModelerとRational® Software Architect(そしてUML)、そして新しいRational® Unified Process(RUP®)ビジネス・モデリング・ガイドラインを統合するための基礎となり、ビジネス駆動型開発を後押しします。

Jim Amsden (jamsden@us.ibm.com), Senior Technical Staff Member, IBM

Jim AmsdenJim Amsdenは、ソフトウェア開発業界のためのアプリケーションやツールの設計開発に20年以上の経験を持っています。彼はボストン大学にてコンピューター・サイエンスの修士を取得しています。関心を持っている領域としては、契約ベースの開発、エージェント・プログラミング、ビジネス駆動型開発、J2EE UML、サービス指向アーキテクチャーなどがあります。「Enterprise Java Programming with IBM WebSphere」の共著者でもあります。現在は、アジャイル開発プロセスをより効率的にサポートするためのツールの統合を探ろうとしています。



2005年 12月 27日

はじめに

ビジネス・アプリケーションの開発は多くの場合、ビジネスの目的を達成するために必要なビジネス要求を発見し、文書化するために、ビジネス・プロセスをモデル化することから始まります。一部のアプリケーションは、WebSphere® Process Serverのようなプラットフォーム・ランタイムを使って、プロセス・モデルとして直接実装することができます。こうしたプロセスでのタスクは、様々な手法を使って実装することができます。しかし、単純に機能を分解してワークフロー・ベースのアプリケーションにするだけでは不十分な場合が多々あります。こうした場合、複雑さを管理し、再利用を促進し、また変更を容易にするためには、他のアーキテクチャー・スタイルを使ってアプリケーションを開発した方が適切かも知れません。ビジネス・アナリストは、プロセス・モデルを使ってシステム機能要求を規定しますが、開発者はオブジェクト・モデルやサービス・モデルを使って実装モデルを規定することを好みます。こうした異なる世界観を、変化するビジネス要求に直面しつつアプリケーションを開発する中でいかに折り合わせ、同期させるかは、あまりよく理解されていません。そのためコストが予想外に高くなる、あるいは顧客の要求から外れたアプリケーションが作られる、などが起きがちです。問題は、プロセス・モデルとオブジェクト・モデルとの関係が適切に定義されていないことです。これもビジネスとITのギャップの反映であり、開発ツールの統合がうまく行かない原因でもあります。

ビジネス・モデリング・ツールとオブジェクト・モデリング・ツールは、その対象が異なることや正式なセマンティクが無いことなどから、統合は困難でした。伝統的なRUP方式では、オブジェクト・モデルの発見手段としてビジネス・モデルを使い、その後、オブジェクト指向の分析、設計、実装においては全面的なモデル・リファクタリングを行いました。注意していないと、こうしたオブジェクト・モデルとビジネス・ユースケースとの関係が失われてしまう可能性があります。このため、ビジネス要求が変化し、実装技術が変化し、また既存アプリケーションが統合されるにつれ、大幅な妥協を迫られることになり、またトレーサビリティにも問題が生じがちです。

この記事は、プロセス・モデルによる手法とオブジェクト・モデルよる手法の良いところを組み合わせた、新しい手法について説明します。この手法ではビジネス・プロセス・モデルを、オブジェクト・モデルが何を実装すべきかを規定する、サービス契約として扱います。BSMは、ビジネス顧客とIT実装者との間のサービス仕様として動的に作成されるUML2モデルです。図1は、このBSMを、プロセス・モデルで表現されたビジネス要求と、(オブジェクト指向またはサービス指向の実装を含めた)任意の実装との間の調停者として示しています。

図1. ビジネス要求を契約によって調停する
図1. ビジネス要求を契約によって調停する

BSMでのビジネス・プロセス・モデルは、プロセスへの参加者や参加者の責務、参加者同士の相互作用のプロトコルなどを規定する、UML2で表現されたコラボレーションと見ることができます。これらの契約は、ビジネス・サービスを必要とする顧客がサービスを利用する上で知っておくべきことのすべて、そして、機能要求に準拠した実装を提供するために実装者が知っておくべきことのすべてを規定します。ビジネス・アナリストはビジネスの機能要求を、ビジネス・プロセス・モデルを使って規定します。次に開発者は、こうしたプロセス・モデルを、(ソフトウェア面でのITの関心事に対応しながら)自分たちが最善の方法で自由に実装できるコンポーネントとサービス契約あるいはそのどちらかと考えます。もしビジネス・プロセスが変更された場合にはサービス仕様も変更され、開発者は新たな機能要求を、自分たちのオブジェクト・モデリング・ツールの中で直接見ることができます。もし実装が変更されても、顧客から見た契約は変更されないため、顧客が影響を受けることはありません。

その結果、オブジェクト指向またはサービス指向の、表現力豊かな分析や設計のモデルを、ビジネス・プロセスやそのタスクに直接結びつけることができます。それによってモデルは理解しやすく、検証しやすくなると同時に、完全なライフサイクルのトレーサビリティを実現することができます。つまり、オブジェクト指向またはサービス指向実装の利点を実現するために、プロセス・モデルをオブジェクト・モデルに変換する必要がなくなるのです。BSMでのサービス仕様は、こうした要求の実装モデルとビジネス要求との間の調停者として動作し、ビジネスとITとの橋渡しをします。

この資料のこれから先では、BSMによるビジネス・モデルとプロセス・モデルの統合の詳細について、またこの統合が、RSM(IBM® Rational® Software Modeler)とRSA(IBM Rational Software Architect)のWBM(IBM® WebSphere® Business Modeler)との統合において、どのようにサポートされるのかについて解説して行きます。もはやWBMからビジネス・モデルをエクスポートしてからRSMにインポートする必要はなくなりました。そんなことをしなくても、RSMは直接WBMビジネス・モデルを開くことができ、それらを、オブジェクト指向の、ビジネス仕様契約やサービス仕様契約、コンポーネント仕様契約として見ることができます。そのため開発者は、RSAの持つ全機能を使って、こうしたサービス仕様を実装することができます。仕様による、実装モデルからビジネス・モデル要素への参照は、自動的に保存されます。ビジネス・モデルでの変更は即座にオブジェクト・モデルの中で見ることができるため、開発者はどんな実装変更が必要かを理解することができます。モデリング・ツール間でのインポート、エクスポートがなく、またモデルのコピーが同期しなくなることもないため、実装モデルとビジネス・モデルとの間のトレーサビリティを完全に保証することができます。

ここではBSMの作成方法や使用方法を、単純な開発のユースケースを使って説明します。このユースケースでは、WBMとRSAを使った簡単な例を開発します。この記事では、ビジネス・サービス・モデルでのビジネス・サービス仕様を、契約と呼ぶことにします。この契約は、ビジネス・プロセスにおけるロール(role)同士の関係と、ビジネス要求を満足するためのロールの相互作用を規定します。こうした考え方は、サービス指向アーキテクチャーの中で復活しつつある契約ベース開発(Contract Based Development)やROOMの概念、それにUML2でのコラボレーションやコンポーネント・モデルに基づいています。


モデリング手法

どのようなソフトウェア・アプリケーションも、何をすべきかを規定した仕様と、その実装方法が必要です。両者を記述する方法として、モデルは比較的上位レベルの方法です。ソフトウェア・モデルの基本的なスタイルとして、今日一般的に使われているスタイルは2つ、つまりビジネス・プロセス・モデルとオブジェクト・モデルです。ここでは、どちらのモデリング・スタイル、あるいはプログラミング・スタイルの方が有利かについての議論はしません。そうした議論は時間がかかる上、自分が知っている方法よりも知らない方法の方が優れていると信じ込んでいる人は、そうした議論で説得できるものではありません。実際には、プロセス・モデルもオブジェクト・モデルも、それぞれ強みと弱みがあります。難しいのは、両者の利点を生かし欠点を避けた上で、ソフトウェア・システムを規定し、構築するための作業全体をいかに削減するか、という点なのです。

下記のサブセクションは、統合のために基礎となる共通用語を示すために、幾つかのモデリング・スタイルを要約しています。これは、ビジネス・プロセスやオブジェクト、コンポーネント、サービスなどのモデルを完全に扱うことを意図したものではありません。また、それぞれが持つ相対的な利点を詳細に説明するものでもありません。ここでは単に、統合に関して知っておくべきことに焦点を当てることにします。

ビジネス・プロセス・モデル

ビジネス・プロセス・モデルは、カタログに分けられるような一連のプロセスで構成されます。各プロセスは、何らかのビジネス・ゴールやビジネスの目的の達成に必要なビジネス・オペレーション上の要求、あるいはビジネス・ユースケースで規定される機能的、非機能的な要求を表現しています。プロセスには幾つかのタスクが含まれており、プロセス中でのタスクを振り付けるコントロール・フローあるいはデータ・フローにリンクされています。タスクは、プロセス中のある作業単位を表し、その詳細はモデルには含まれません。タスクは他のプロセスを呼び出すことができ、(手動のサービスを含めて)他が提供するサービスを呼び出すことができ、プロセス・モデルの一部として定義されるローカル機能またはグローバル機能を呼び出すことができ、またその他、プロセス・モデラーの観点からは分割不可能な計算を実行することができます。こうしたプロセスはビジネスに関するものであり、必ずしも自動化されたソフトウェア・プロセスに関するものではありません。ビジネス・プロセスは、ビジネス要求をとらえるために一般的に行われる方法の一つにすぎません。この他にも、ビジネス・ルールやビジネス・ユースケースなど、使用可能な手法は数多くあります。しかしこの記事では、単純にするため、そして一般的に使用されていることから、ビジネス・プロセス・モデルに視点を絞ることにします。

タスクには、そのタスクを完了するために(例えば、ある特定な場所で)必要となるリソースを割り当てることができます。多くの場合、こうしたリソースの少なくとも1つは、ビジネス組織のどのロールがタスク実行に責任を持つかを規定するロール・リソース、または、あるサービス・プロバイダーが実行すべきサービスを規定するロール・リソースです。一部のタスクは手動であり、充分なスキルを持ち、そのタスクに割り当てられたロールを果たす資格を持った人によって実行されます。それ以外のタスクは自動化されており、そのロールを果たす、ソフトウェア・アプリケーションのコンポーネントによって実行されます。プロセスは、プロセスの目的達成に必要な、ロールが行うタスクを振り付けます。こうした振り付けや通信プロトコル、あるいはオーケストレーションを規定する補助として、プロセスには、別の実行パスを選択するための、あるいは並列コントロール・フローの分岐やマージのための、あるいは繰り返しのための、他のコントロール・ノードやループ・ノードが含まれる場合があります。

ビジネス・プロセス・モデルは比較的単純であり、明確なビジネス価値に対応する、特定な、識別可能なタスクに焦点を絞っているため、ビジネス・アナリストにとって魅力的です。私達は皆、何らかの最終結果を達成するためのステップ・シーケンスや処方に従うことに慣れています。既存の、あるいは期待されるビジネス・プロセスは、ビジネスの中のステップを直接反映しているため、プロセス・モデルでとらえることは非常に容易です。

プロセス・モデルを直接実行できるワークフロー・ベースのシステムとして、WebSphere Process Serverがあります。これは、単純なビジネス・プロセスのソリューションとして効果的です。しかし、ビジネス・プロセスが複雑になると、あるいは新しいビジネス要求に対応するためにプロセスが変化すると、あるいは再利用のためにプロセスが分解されリファクターされると、こうしたシステムではうまく行かなくなります。プロセス・モデル(そして機能的な分解)に基づく大きなアプリケーションの場合、アプリケーションの状態は予測不能な形でシステム全体に分散されており、また実装は呼び出し側、呼ばれる側という関係で密結合されているため、アプリケーションは理解しにくく、また維持管理コストも高くなりがちです。このような結合や複雑さがあると、アプリケーションを再利用することも他のアリケーションと統合することも難しくなりがちです。

オブジェクト・モデル

OOT(Object-oriented technology)では、IDや、状態と振る舞いのカプセル化、継承と多相性(polymorphism)、そしてメッセージによる通信といった概念を導入しています。OOTによって、ソフトウェア・システムの複雑さや維持管理コストを大幅に低下させることができ、また再利用を促進することができます。

OOTは、システムの複雑さの低減、変更の管理、そして再利用の促進などに有効であることが実証されています。状況によっては、ビジネス・プロセスにOO(object-oriented)実装を利用すると有利かも知れません。しかし、ビジネス・プロセスとそれによって表現されるビジネス要求と、OO実装との関係はどうなのでしょう。同じビジネスの結果を達成するために相互作用を行うドメイン・オブジェクトを発見する補助としてビジネス・プロセス・モデルを使い、ビジネス・プロセス・モデルをOO実装に変換するのでしょうか。

こうした方法は繰り返し論じられていますが、あまり成功してはいません。ビジネス・プロセス・モデルとオブジェクト・モデルの間には何も正式な関係がないため、多くの場合、変換は予測不能であったり不完全であったり、再現不能であったりします。またトレーサビリティも予測不能なため、ビジネス・モデルが変更されてしまうと、オブジェクト・モデルで対応することは非常に困難です。ビジネス・プロセス要求の変換をユースケース分析やOO分析、設計、実装、テスト、デプロイなどによって手動で変換しようとすると、元々のビジネス要求とデプロイされる実装との間に大きな差ができてしまいます。

OOTを使ってビジネス・システムを直接モデル化することはできますが、ビジネス・プロセスはコラボレーションを行うオブジェクトに埋もれてしまうため、ビジネス・アナリストから見えにくくなります。ビジネス・アナリストにも開発者にも有利なようにプロセス・モデルとオブジェクト・モデルを統合するにはどうすべきなのでしょう。下記のセクションでは、これについて調べて行きます。

コンポーネント・モデルとサービス・モデル

最近のエンタープライズ・アプリケーションは、分散性や永続性、セキュリティー、整合性、統合、そして柔軟なデプロイなど、多くの関心事に対応する必要があります。こうした関心事はすべて、ソフトウェア・ドメインを導入することによって生じます。また、ビジネスからIT組織への要求が増大するにつれ、ソフトウェア・アプリケーションも影響を受けます。つまりビジネスはアプリケーションに対して、より多くを行い、構築時間が短く、どこでも利用でき、新たなビジネス機会を満足するために容易に変更でき、そして他のビジネス・パートナーからのアプリケーションとの統合が容易なように、と要求します。その上さらに、予算も開発者のスキルも制限されているのです。こうした要求すべてに答える複雑な分散ビジネス・アプリケーションを、オブジェクト指向の言語や開発ツールを使って構築することは可能です。しかしオブジェクト指向技術を利用すると、継承やオブジェクト参照によって密結合されたシステムになりがちであり、そのためパフォーマンスは低く、また柔軟なデプロイも困難になりがちです。こうした結合は、クライアントが自分たちの使用するサービスの実装を知りすぎていることから生じるのです。

コンポーネント・ベース、あるいはサービス・ベースの開発では、仕様と実装が明確に分離されるため、伝統的なOO開発を拡張することができます。この分離によってシステム内の部分同士の結合が低下するため、そうした部分を他のコンテキストで再利用したりデプロイしたりすることが容易になります。コンポーネントは、開発時やデプロイ時、あるいは実行時にも、必要機能を提供するコンポーネントを参照するサービスを使うことによって連結することができます。あるコンポーネントの実装は、新しい実装がそのコンポーネント仕様を実現する限り、クライアントに影響を与えることなく新しい実装で置き換えることができます。

コンポーネント仕様は、サービスを要求するクライアントと、サービスを提供する実装者との間の契約を定義します。この契約は2つの部分から構成されています。静的部分、つまり使用契約(usage contract)は、提供されたサービスを使用するためにクライアントが知っておくべきことを規定します。使用契約は、コンポーネントが提供するインターフェースや、コンポーネントが機能するために何が必要かを規定するインターフェースによって定義されます。こうしたインターフェースに含まれるものとしては、利用可能なオペレーションや、そうしたオペレーションのための入出力パラメーター、起こり得る例外、クライアントがオペレーションを呼び出す前に満たすべき事前条件、クライアントが呼び出し後に期待される事後条件などがあります。こうしたオペレーションは、緊密に連携した提供されるサービスや必要なサービスから構成される機能や責務を表現しています。

契約の2番目の部分である実現契約(realization contract)は、契約を満足するために実装者が何をすべきかを規定します。つまり実現契約は、実装によって実現すべき通信プロトコルや状態ベース・プロトコル、あるいは、維持管理すべきサービスの具体的なオーケストレーションやコレオグラフィーを規定します。これは、ビジネス・プロセスでモデル化されたものと同じであることに注意してください。この詳細については、次のセクションで説明します。

UML2で契約をモデル化するには、Collaborationを使うのが一番です。使用契約は、コラボレーションの参加者において動作するコラボレーション・ロールによって規定されます。こうしたロールのタイプ(多くの場合はサービス・インターフェース)は、そのロールを果たす任意のサービス・プロバイダーが提供すべきサービスを規定します。ロール同士のコネクションは、ロール同士の相互作用を、またロール同士が通信しあうためのポートを示します。コラボレーションに含まれるものには、実現契約を規定する振る舞いやアクティビティー、相互作用、状態マシンまたはプロトコル状態マシンなどがあります。

契約は、«specification» のコンポーネントとしてモデル化することもできます。コンポーネントが実現するインターフェースは提供されるインターフェースを定義しますが、«use» の依存関係は必要なインターフェースを規定するために使用されます。あるいは、提供されるインターフェースや必要なインターフェースを示すために「ボールとソケット(ball-and-socket)」表記を使うこともできます。実現契約は、«specification» のコンポーネントに追加された振る舞いとしてモデル化することができます。この振る舞いは、アクティビティーの場合もあり、相互作用の場合もあり、あるいは状態マシンの場合もありますが、コンポーネントの実装者が行うアクションのオーケストレーションを表現します。コンポーネント実装は、契約を定義する«specification» のコンポーネントを指す«realize»の依存関係を持った«implementation» コンポーネントとして示されます。同じ«specification» コンポーネントは、それぞれ異なるアーキテクチャー特性や非機能的特性を持った多くの«implementation» コンポーネントによって実現することもできます。

契約のモデル化にコラボレーション・コンポーネントを使用するか仕様コンポーネントを使用するかは、好みの問題です。この記事の、これから先ではコラボレーションを使います。これは、コラボレーションによって参加ロール間の相互作用パターンも表現できること、またそうしたパターンが、多くの具体的状況に対してインスタンス化できるためです。コラボレーションは、特別なビジネス契約に関する問題領域に焦点を絞ることによって、不必要な詳細を省略することができます。またコラボレーションは、実装コンポーネントの中でサービス・プロバイダーがどの程度具体的なロールを果たすかをモデル化するためにも便利です(この場合には、コンポーネントの一部をCollaboration のcollaborationRolesにバインドするCollaborationUseを使います)。

ビジネス・サービス仕様が実現するビジネス要求を上位レベルで見るために、また非機能的特性を規定する場として、ビジネス・ユースケースを使うことができます。こうしたビジネス・ユースケースは、コラボレーションで対応すべきビジネス要求を契約として表現した、コラボレーション・コンポーネントまたは仕様コンポーネントによって実現されます。


ビジネス・サービス・モデリング

ビジネス・プロセス・モデルで表現されたビジネス機能要求と、OO実装とを、どのように関係付けるのでしょう。答えは、プロセス・モデルから派生するサービス仕様、またはサービス契約によって関係付けるのです。この仕様、または契約は、何を実装すべきかを規定しますが、いかに実装すべきかは規定しません。こうした契約は、ビジネス・プロセスから直接派生するものであることから、ビジネス・サービス仕様(Business Services Specification)と呼ばれます。ソフトウェア・システムよっては、こうしたサービス仕様のすべてを実装する必要はありません。しかし自動化されたビジネス・プロセスのサブセットに対しては、ビジネス・オペレーション要求とそのソフトウェア実装モデルとの調停は、サービス仕様が行います。サービス仕様は、要求を実現するために実装が何をすべきかを規定した、正式な、サービス指向の、そして検証可能な仕様なのです。

ビジネス・プロセス・モデルの中の各プロセスは、UML2 コラボレーションと見なされます。コラボレーション・ロールは、プロセス中のタスクを実行するように割り当てられたロール・リソースから派生します。ロールはUML2 インターフェースと見なされ、そのオペレーションやシグネチャーは、そのロールが参加するプロセスの中でロールに割り当てられたすべてのタスクから派生します。オペレーションのパラメーターは、対応するタスクの入力と出力から派生します。これによって、参加ロールとそれらに必要なインターフェースが規定でき、ビジネス・プロセスに対する完全な使用契約とすることができます。

実現契約は、コラボレーションに追加されるアクティビティーの振る舞いです。このアクティビティーは、ビジネス・プロセスそのものから直接派生します。プロセスの中の各タスクは、アクティビティーの中のオペレーション呼び出しになります。このオペレーション呼び出しに対するターゲット・インスタンスは、タスクが割り当てられているロールに対応するインターフェースのインスタンスです。他のプロセス・モデル要素の大部分はUML2アクティビティーのモデル要素に密接に対応するため、ビジネス・プロセスからアクティビティーへの変換は単純です。

各プロセスも、ビジネス・プロセスが実現するビジネス要求を規定したビジネス・ユースケースを実現することができます。このユースケースに参加するアクターは、そのビジネス・プロセスに参加するロールとサービス・プロバイダーから派生するビジネス・アクターです。またビジネス・ユースケースは、コラボレーションによっても実現することができます。このことから、要求を満足するための実装方法を、契約で規定できることが分かります。

ビジネス要求を満足するエンド・ツー・エンドの開発を実現するためのツール統合の指針となるのは、こうした正式な関係です。追加の、標準から外れた依存関係は必要なく、また、ビジネス・プロセス・モデルとUML2でのBSMとの間でトレーサビリティが失われることもありません。これは、BSMがビジネス・プロセス・モデルのビューであり、それ自身で独立した永続的なモデルではないためです。

そうするとビジネス・サービス仕様は、CollaborationUseを含んだ任意の分類子によって実現することができます。分類子は自分の部分(プロパティーと関連端)をコラボレーションの中のロールにバインドすることによって、規定された契約を満足する実装を提供します。こうした分類子の構成方法には何も制約はありません。アーキテクトは、他のIT要求、つまりビジネス・サービス仕様での要求を上回るシステム・ユースケースや、アーキテクチャー上の、非機能に関する関心事などで規定される要求に対応するシステムを設計することができます。その結果、実装をいかにモデル化し、実行コードに変換するかを、非常に自由に決めることができます。しかし最終的な実装では、契約で規定されビジネス・プロセス・モデルに必要なロールから生成される必要インターフェースは、何らかの形で実現され、その振る舞いは、実現契約を規定したビジネス・プロセスと一貫性を保ちます。その結果、ビジネス要求とOOのIT実装とのギャップは、正式な、よく定義された、決定論的な、そして反復可能な方法によって、効果的に埋めることができます。

ビジネス・オペレーション要求の、どの部分をソフトウェア・コンポーネントで自動化するかを決定してシステム境界を確立すれば、サービス仕様を実現する実装の開発を始めることができます。そうした実装は、追加のシステム要求(タスクの詳細や、アーキテクチャー上の、そして非機能的な要求など)をモデル化するシステム・ユースケースから始まるかも知れません。システム・ユースケースは、サービス仕様が規定するビジネス上の関心事と混ぜ合わせることなくIT上の関心事や設計制約をシステムに含める上で、非常に便利な方法です。システム・ユースケースとビジネス・ユースケースは、それぞれ異なる関心事に対応するため、両者を直接結びつけることはできません。その代わり両者は、分類子の実装や両者が実現するサービス仕様などを通して、間接的に結びつけられます。

BSMには、ビジネス・プロセス・モデルの中の全プロセスに対する仕様が含まれています。BSMは大まかに、OMGのMDA(Model Driven Architecture)フレームワークのCIM(computation-independent model)に対応します。BSMは実装が何をすべきかを規定しますが、アプリケーションやソフトウェア・アーキテクチャー、ミドルウェア、ランタイム・プレットフォームの面から、どのようにすべきかは規定しません。契約の実装は、OMG MDAのPIM(platform independent model)に対応します(PIMは、どんなビジネス契約が実装され、どのように実装されるかを規定します)。

ビジネス・サービス・モデリングとRUP

RUPでのBusiness Use Caseモデリングは、「一連のビジネス・ユースケース・インスタンスを定義します。ここで各インスタンスはビジネスが実行するアクション・シーケンスであり、ある特定なビジネス・アクターに対する、観測可能な、価値を持つ結果を発生します。」つまりRUPは、ユースケースはシステムへ要求を記述するもの、という見方をしており、アクターに対して、そのシステムのユーザー、あるいは参加者としての価値を提供しているのです。この価値は、ビジネス・ユースケースが実現するビジネス・ゴールと目的の中で記述されます。そしてビジネス・プロセス・モデルは、こうしたビジネス・ユースケースの要求を満足するためのビジネス・オペレーション要求を規定します。

BSMは、ビジネス・オペレーション要求と、その実現との関係を正式化するものです。これによって、ビジネス・プロセス・モデルからビジネス・サービス・モデルへの移行が容易になり、よりうまくSOAランタイム・プラットフォームに合致する、柔軟な実装が可能になります。ビジネス・サービス仕様によってビジネス・プロセスを別の角度から眺め、同じビジネス・ユースケースを実現することができます。そのサービス契約を実現するためには、非常に様々な、そして進化する方法があるはずです。これによって、ビジネス上の目的と要求に関する関心事を、目的に合致するためのビジネス・オペレーション上の関心事から分離し、またこうしたオペレーション要求(の一部)を自動化するソフトウェア・システムがすべきことを規定するビジネス・サービス仕様から分離し、そして、実際にそれを行う実装からも分離することができます。これによって、仕様と実現は対になりながら、正式で追跡可能な関係、あるいはそれらの間の統合を維持しながら、関心事を分離できるのです。

ビジネス要求を満足するエンド・ツー・エンドの開発を実現するために、ツール統合の指針となるのは、こうした正式な関係です。IBMではこれを、「ビジネス駆動型開発(Business Driven Development)」と呼んでいます。この方式でのシステム開発は、ビジネス・ゴールと目的から始まって、それらに合致するプロセス・モデルやサービス契約モデル、実装、デプロイメントなどによって駆動されます。そうするとデプロイされたシステムは、ゴールと目的が満足されているかを調べるためのKPI(Key Performance Indicator)情報が収集、監視される一方、新たなビジネス機会の進化やサポートに必要な情報を提供します。

RUPは開発に関して、要求から分析、設計、実装、そしてテストまで、連続的な推敲(elaboration)を行います。ビジネス駆動型開発は、この推敲を実現する1つの方法を、サービス指向ビューによって規定しています。この方法では、開発ライフサイクルの任意の時点で、利害関係者やモデラーの関心事をとらえたサービス契約を、関心事の対応方法や実現方法から分離してモデル化できる、としています。そうすると、このサービス仕様または契約は、実現に必要な追加の関心事を導入する何らかの別モデルによって実現することができます。この実現されたものが、今度は再帰的実現に対する契約になります(あるいは契約と見ることができます)。再帰的実現は、機能的、非機能的な要求を満足するために必要なものがすべて対応されるまで、次々と別の関心事を導入します。この、関心事の分離は、推敲ステップ間に正式で追跡可能な関連付けを持つ、連続的推敲の実行手段としての契約ベース開発によって正式化されます。この手法では、新興のSOAを利用するかも知れません。そして、抽象化レベルとシステムの部分との関係が、より正式で反復可能なものになるかも知れません。これによって、OMGのMDA(Model Driven Architecture)を別の観点から見ることもできるでしょう。このプラットフォームは1セットの関心事でしかありませんが、ビジネス・プロセス自体や、ビジネスをサポートするアプリケーション用のアーキテクチャー・フレームワークに関係したものが、他にも数多くあるかも知れません。この、関心事の分離と統合こそが、MDAの核心なのです。

RUPは、ビジネス駆動型開発とBSMの概念を一部採り入れて、アップデートされています。RUP Plug-In for WBI Modelerを参照してください。


統合されたプロセスの例

ビジネス・モデルとオブジェクト・モデルの統合を理解するためには、具体的な例を見るのが一番です。このセクションでは、この統合をWBMとRSMの統合を使って説明しながら、典型的なビジネス駆動型開発ユースケースに基づいて単純で具体的な例を作って行きます。

この例はIBMのIAA(Insurance Application Architecture)モデルの一部であり、デモ用によく使用されるものです。この例では、保険請求を確立し、管理するプロセスを処理します。

ビジネス駆動型開発のユースケース

この例を構築し、ビジネス・モデルとオブジェクト・モデルの統合の使い方を示すために、単純化されたビジネス駆動型開発プロセスを使います。このプロセスは、ビジネス・プロセス・モデルやオブジェクト・モデル、あるいはアプリケーションの生成やデプロイなどに関するすべての面に対応するためのものではありません。ビジネス・プロセス・モデルとオブジェクト・モデル統合のコンテキストを、単純ながら典型的なエンド・ツー・エンド開発プロセスを通して解説し、全体的な概要を示すことが目的です。

この、単純化したビジネス駆動型開発プロセスのステップは次の通りです。

  1. ビジネス・ゴールと目的をとらえる
  2. ゴールと目的に合致するための要求を規定するビジネス・ユースケースをとらえる
  3. ビジネス・ユースケースを実現するために主要なビジネス・プロセスを発見し、とらえる
  4. ビジネス・プロセスの現在の姿と、あるべき姿をシミュレーションし、必要に応じて改善する
  5. ソフトウェア自動化の機会を判断する
  6. 選択された何らかのアーキテクチャー・パターンを使ってBSMを実現する
  7. サービス実装を生成し、デプロイする
  8. プロセス・コレオグラフィーを生成する
  9. タスクをサービス実装にバインドする

ステップ7からステップ9は、この記事の範囲外のため、将来、ビジネス駆動型開発に関する記事の中で議論する予定です。下記のセクションでは、ステップ1からステップ6を詳細に検証しながら、ビジネス・アプリケーションをモデル化し、実装するためのWBMとRSAの使い方を説明します。

ビジネス・ゴールと目的をとらえる

ビジネス駆動型開発は、経営層が実現しようとしているビジネス・ゴールと目的をとらえるところから始まります。こうしたゴールと目的を持っていないと、ソフトウェア・システムが実際にビジネス価値に貢献しているのかどうかが分かりません。開発プロジェクトよる投資回収の実現状況が分からず、そのため機能強化や、その後の追加作業のための予算追加も正当化しにくくなります。

効果的な開発を行うためには、ゴールと目的はSMARTでなければなりません。つまり、Specific(具体的)、Measurable(測定可能)、Achievable(達成可能)Realistic(現実的)Time-bound(時間制限付き)でなければなりません。SMARTなゴールは、数量化でき、検証することができます。各ゴールは、そのゴールに達したかどうかを知るための情報を規定した、1つ以上のKPIを持っている必要があります。開発プロセスが進むと、こうしたKPIを使って観察モデル(observation model)を設計します。こ観察モデルは、デプロイされたソフトウェア・アプリケーションの監視方法を規定します。それによって、ビジネス・ゴールが満足されているかの検証データを収集するのです。

ビジネス・ゴールと目的、そしてそれらのKPIは、IBM® Rational® RequisitePro®データベースの中に収められます。そうすると、ビジネス・プロセスやビジネス・ユースケース、サービス仕様(下記で説明します)を、それらが達成しようとしているゴールと目的に逆リンクすることができます。これによってトレーサビリティ、つまりビジネスのゴールと、それを実現するビジネス・プロセス、そしてビジネス・プロセスを実現するサービスとの間のトレーサビリティを実現することができます。

ゴールと目的をモデル化することは、この単純な例では範囲外です。この例では、ビジネス・プロセス・モデルと、コンポーネント・モデルまたはサービス・モデルとの関係に焦点を絞ります。ただし、正しいものを正しい方法で開発する上で、この重要なアクティビティーが開発プロセス全体のどこに当てはまるのかを理解することは非常に重要です。またゴールと目的は、仕様と実現の再帰的な対における根本契約も表します(この再帰的な対は、ゴールと目的の実現に必要な全ての関心事に対応します)。

ビジネス・ユースケースをとらえる

ゴールと目的が文書化されると、ビジネス・アナリストは、そのゴールと目的を満足するための要求事項に注意を向けます。こうした要求事項はRequisiteProのBusiness Use Casesの中にとらえることができ、実現すべきビジネス・ゴールと目的にリンクされます。ビジネス・ユースケースは、外部参加者とビジネス機能要求との間の、価値を生み出す相互作用を記述します。ビジネス・ユースケースは、単純であることや、非公式なものであること、しかも単純でよく知られたツール・インターフェースを持っていることなどから、こうした上位レベルの機能要求をとらえるために効果的であり、経営層やアナリストにとって「とっつきやすい」方法です。

ビジネス・ユースケースのモデル化も、この単純な例では範囲外ですが、ビジネス・ゴールと目的に重要な関係があること、そしてユースケースを実現するビジネス・プロセスとの関係から、ここで説明しておくことにします。正式なモデル化と非公式なモデル化を橋渡しする上で、ビジネス・ユースケースのモデル化は重要です。また多くの場合、ビジネス・ユースケースをモデル化することによって、ビジネス上の利害関係者が意識する重要な機能要求をとらえることができます。

主要なビジネス・プロセスを発見し、とらえる

次の開発ステップでは、ビジネス・ユースケースがとらえた機能要求を実現する、主要なビジネス・プロセスを、WBMを使って発見し、設計し、文書化します。このステップではソフトウェアについては気にせず、また、どのプロセスやタスクを自動化するかも無関係です。むしろこのステップで焦点を当てるのはビジネスやビジネス要求であり、またこうしたビジネス要求を満足する、観測可能な、あるいは期待されるプロセスです。多くの場合、こうしたプロセスは、ビジネスの中で発生する特定なシナリオを観察することで発見できます。効率を改善するために、新しい市場機会を開拓するために、あるいは、これまで分離していたビジネス単位を統合するために、新しいプロセスが設計されます。

プロセス・モデルが注目するのは、ビジネスをサポートするために実行される(あるいは実行すべき)具体的なビジネス・プロセスや、誰がプロセス中のタスクに責任を持つのか、どんなリソースが必要なのか、プロセス実行のコストはいくらなのか、そしてプロセス実行にかかる時間、などです。ビジネス・プロセスをモデル化するためには、ビジネスに関して幾つかの質問に答える必要があります。つまり、

  1. どんなビジネス要求を実現するのか?
  2. 目的を実現するために、どんなタスクを実行すべきか?
  3. こうしたタスクを、どのようにオーケストレーションするか?
  4. (組織の中の)どんなロールが各タスクの実行に責任を持つのか?
  5. 必要なスキルや許可は何か?
  6. タスクを満足するために必要なリソースとして、他に何があるか?
  7. そうしたリソースはどこにあり、コストはいくらなのか?
  8. 各タスクに要する時間は?
  9. タスクのコストは?
  10. どんな情報がタスクの実行に必要なのか?
  11. この情報はどこから来るのか、またタスクの完了後はどこに行くのか?
  12. タスクのパフォーマンスによって、情報はどのように変更されるのか?
  13. ビジネス組織は、必要なロールをどのようにサポートするのか?
  14. 他のものが提供すべきサービスとして、何が必要なのか?

ここに取り上げる例では、こうした質問のすべてには答えませんが、その代わり、既に発見され検証された単純なビジネス・モデルを取り上げます。IAAモデルには、こうした質問を保険請求処理の問題に適用した場合のプロセス例が含まれています。このモデルの全体的な構成は、図2のWBM Project Treeに示されています。

図2. IAADemo Project Tree
図2. IAADemo Project Tree

この一連のプロセスのビジネス・データは、図3のBusiness Itemsカタログの中に構成されています。

各ビジネス・アイテムは、任意の数の型付き属性を持つことができます。その一部は基本型であり、その他は非基本型です。この属性は、ビジネス・アイテム間の関連付けを示します。この関連付けは、拡張可能なビジネス・アイテム属性として示されています。プラス記号上でクリックして要素を拡張すると、関連付けられたビジネス要素のプロパティーが示されます。

図3. Claim Folder Business Item
図3. Claim Folder Business Item

図3は、IAADemoビジネス・モデルの中で使われているビジネス・アイテムのリストを示しています。ClaimFolderを選択して開くと、保険請求に関して収集された全情報を表示します。ClaimFolderには、親テンプレートとしてDataStructureがあることに注意してください。テンプレートは、親がテンプレートであるようなビジネス・アイテムに含むべき一般的な属性を規定するために使われます。

WBMでは、こうしたビジネス・アイテムは、プロセス・モデルの中のタスクやプロセスの間で交換される情報を表現します。これらはビジネス・ドメインの実体に直接対応する場合もありますが、多くの場合は直接には対応しません。むしろこれらはビジネス・ドメイン・データのサブセット、あるいはビューを表し、ビジネス・プロセスのタスク間での特定なメッセージ交換またはデータ交換のコンテキストで使用されます。永続的なビジネス・ドメイン・オブジェクトは、ビジネス・プロセスでのリポジトリーとしてモデル化されることが多いものです。これに関しては、UML2でのサービスや永続性エンティティ、データ転送オブジェクトなどのコンテキストで、さらに説明することにします。

図4は、典型的なビジネス・プロセスを示しています。Administer Claim(請求管理)プロセスは、ある特定な請求を、そのライフサイクル全体を通して処理します。このプロセスには、上記で説明したビジネス・アイテムの1つである、ClaimContainerという型のclaimContainerという入力があります。この入力には、このプロセスに必要なデータがすべて含まれています。このデータは、プロセスの中の様々なタスクが使用し、アップデートします。

図4. Administer Claimビジネス・プロセス
図4. Administer Claimビジネス・プロセス

Administer Claimプロセスでは、Notify No Coverage(請求対象外通知)タスクが、このクレーム・コンテナーを入力として持ち、同じデータ・アイテムを出力します。このタスクは、このタスクの実行責任を持つロールである、Claim Processorに割り当てられます。

図5に示すモデルの中のあるリソースは、人、あるいは他のビジネス・システムが果たすロールと、そのタスクの完了に必要な他の任意リソースを定義します。

図5. IAADemo Projectリソース
TIAADemo Project Resources

ビジネス・プロセスの現在の姿と、あるべき姿をシミュレーションする

ビジネス・モデルのシミュレーションは、ビジネス・モデルが要求された機能を実行すること、充分なリソースがあること、そして意図したビジネス目的を実現していることを検証するために使われます。またシミュレーションは、ボトルネックを判断するために、またコストを最小化しサービスを最大化するためのビジネス・プロセスの最適化にも使われます。

シミュレーション・データは、ビジネス・プロセス仕様の一部ではないため、UML2のビジネス・サービス・モデルでは見えません。ですからこの例では、ビジネス・プロセスのシミュレーション方法やアップデート方法の詳細には触れないことにします。WBMとRSAは、さらに統合できるかも知れません(例えば、シミュレーション・データを使ってテストケースを作る、あるいはデプロイ時のロード・バランシング用データを提供する、など)。

ソフトウェア自動化の機会を判断する

ビジネス・プロセスが(ある望ましいレベルで)完了し、検証されると、顧客やビジネス・アナリスト、アーキテクト、そして開発者は、ソフトウェア自動化の候補とすべきものはビジネス・モデルのどのタスクかを判断するために、協議を行います。その結果として下される決定は、多くの場合、ビジネスの目的やコスト、市場導入までの時間、期待されるアプリケーション寿命などに基づいて行われます。このステップの結果、サポートするソフトウェア・システムが実装すべき、従ってシステムへの初期要求を表現した、プロセスやタスク、サービスなどのリストができます。

BSMはビジネス・プロセスを使って定義され、プロセスに参加するロール間の契約や、こうしたプロセスやタスクの実装を規定します。これは、ビジネス・プロセス・モデルとオブジェクト・モデルとを統合する上で、主要な概念です。WBMは、プロセス・モデルを作るために使われます。このプロセス・モデルは、満足すべき契約の実装(UML2でモデル化され、RSAを使って構築されます)を規定したビジネス要求をとらえたものです。この統合は、(UML2で表現された)こうした契約の仕様と実現の中で正式化されます。これについては先に説明しましたが、この先のセクションでも説明します。

いったん契約が満足できると、プロセス・コレオグラフィーをBPEL(Business Process Execution Language)プロセスとしてWBMを使って生成すること、そして、こうしたプロセスで呼び出されるタスク(BPELでの呼び出しアクティビティー)を、RSAが作成する、対応のサービス実装にバインドすることは比較的簡単です。これは、WBMが規定する契約をRSAが実装するため、実装成果物とビジネス・プロセスとの同期が保てるためです。

BSMを実現する

WBMとRSA、あるいはRSMを使うには、WBIMのバージョン5.1.1.2以降、RSMあるいはRSAバージョン6.0.0.1以降(6.0.1.1が望ましい)が必要です。IBM®のRPU(Rational® Product Updater)を使って、必要なアップデートと機能をインストールして適用します。ビジネス・サービス・モデルを見るためには、RSMまたはRSAのいずれかを使います。RSMは、サービス仕様実装の分析モデルや設計モデルを作るために使うことができます。RSAには、他にも多くのツールが用意されており、設計モデルを実装するためのコード生成に使うことができます。この例では、分析モデルと設計モデルに対して、RSMとRSAを交換可能なものとして扱っています。

これで、ソフトウェア自動化のために選ばれた幾つかのタスクを実装する準備ができました。最初にすることは、設計成果物と実装成果物をモデル化するための新しいRSMモデルを作る(あるいは既存のRSMモデルを開く)ことです。この例では、モデリング・プロジェクトの中で、IAADemo Designという実装モデルを構築します。

この設計モデルは、幾つか重要な理由から、ビジネス・プロセス・モデルとは別のモデルでなければなりません。第1の理由は、実装と仕様を完全に分離するためです。これによって、様々な場合、様々なプラットフォームにおいて、ビジネス・プロセス契約を様々な方法で実装しやすくなります。あるいは、いくつかのフェーズにまたがるリリースに対して、自動化されたビジネス・プロセス一部のみを実装、デプロイすることができます。

別モデルを使用するもう1つの理由は、ビジネス・プロセス・モデルは、実装者が実装すべき契約を表現しているためです。実装者が、新たに発見された要求に応えるためにビジネス・プロセスを変更しようとして、ビジネス・アナリストと協議せずに契約を変更しようとするのは不適切です。そんなことを許すと、ビジネス要求を満足できなくなる危険性があります。そのためWBMビジネス・プロセス・モデルは、誤って契約が変更されないように、RSAから契約として見る場合には読み取り専用になっています。しかし、ビジネス・プロセス契約の様々な部分を見るためにRSAを使ってダイアグラムを作ることは、相変わらず可能です。WBMビジネス・モデルを参照する別モデルでは、とにかくこうしたダイアグラムを作る必要があるのです。

RSAでのWBMモデルにアクセスし、ビジネス・サービス仕様を見る

ビジネス・プロセス・モデルでのタスクを実装するためには、クライアントがタスクを使う上で知っておくべきこと、そしてタスクが何をするのかを規定した契約が必要です。この情報は、UML2でのBSMとして見た、WBMモデルから得ることができます。このモデルにアクセスするためには、ファイル -> インポート -> 既存のプロジェクトをワークスペースへを使って単純にWBMプロジェクトをRSAワークスペースにインポートするか、あるいはバージョン管理リポジトリーからチェックアウトします。既存のプロジェクトを使用する場合は、ファイルは実際にはコピーされません。その代わり、そのWBMプロジェクトと物理的に全く同じファイルを含んだ新しいモデリング・プロジェクトが、RSAワークスペースに作られます。WBMがこうしたファイルに加える変更は、そのプロジェクトが更新されると即座にRSAプロジェクトの中に反映されます。WBMとRSAが別の製品としてインストールされ、同じワークベンチでは実行しない場合、あるいは同じワークスペースを共有しない場合には、プロジェクトを共有することが必要です。WBMとRSAは、お互いに外部アプリケーションとして見えますが、両者で同じファイルを共有することができます。

WBMプロジェクトがRSAプロジェクトにインポートされると、WBMのリソースは、RSAのModel Explorerで見ることができます。これを図6に示します。

図6. IAADemoのWBMモデルとRSA設計モデル
図6. IAADemoのWBMモデルとRSA設計モデル

図6に示すIAADemoプロジェクトの内容は、先に見た図2の、WBMのプロジェクト・ツリー・ビューと同じには見えません。これは、RSA モデル・エクスプローラーを使ってプロジェクト内の実際のファイルを見ているためです。これらのファイルはWBMのIAADemoプロジェクトの中にあるのですが、プロジェクト・ツリー・ビューでは隠れています。WBMでこれらを見るには、ナビゲーター・ビューを使います。今後のRSAリリースでは、WBMプロセス・モデルは、もっと論理的にRSA モデル・エクスプローラーの中で見えるようになるはずです。

必要であればモデリング・パースペクティブに切り換え、resoures.XMIというファイルの上でダブル・クリックしてビジネス・サービス・モデルを開きます。あるいは、resoures.XMIを選択して右クリックし、開くあるいはアプリケーションから開く -> Rationalモデル・ファイルおよびダイアグラム・エディターを選択します。RSAは、UML2でのビジネス・サービス・モデルに変換されたビジネス・プロセス・モデルの内容を表示します。これを図7に示します。このファイルは、モデル・エクスプローラーではRSMモデルとしてしか開けないことに注意してください。ナビゲーター・ビューなど他のビューからは、テキスト・ファイルとして開かれます。

図7. IAADemoのBSMを開く
図7. IAADemoのBSMを開く

resources.XMIというファイル(またはEclipseリソース)は、完全なWBM IAADemoビジネス・プロセス・モデルを表現します。このファイルを開くと自動的にUML2のBSMに変換されるため、RSAまたはRSMでは、ごく普通のUML2モデルのように見えます。このUML2モデルは保存する必要はありません(ただしファイル -> 別名保管を使って、.emx拡張子を持つRSAモデルとしてビジネス・サービス・モデルを保存することは可能です)。しかし、WBMビジネス・プロセス・モデルはRSAでは読み取り専用です。変換されたUML2モデルに変更を加え、改めてWBMのresources.XMIファイルに保存することはできません。そうした変更は、ファイル -> 別名保管を使って別の.emxファイルに保存する必要があり、そうすることによって、そのビジネス・プロセス・モデルのコピーができます。しかしこれをしてしまうと、モデルのWBMコピーとRSAコピーとの同期に問題が起きるため、こうした習慣はお勧めできません。WBMからRSAへの統合において、WBMからモデルをエクスポートしてRSAにインポートしないのは、こうした理由があるためです。

推奨の方法としては、RSAで実装すべきことを規定した、読み取り専用の仕様としてビジネス・サービス・モデルを扱うことです。この仕様は、他の利害関係者との協議を通してしか変更できず、しかもそうした変更は、すべてWBMを使って行われます。resources.XMファイルを開く時には、必ず変換が再実行され、すべての変更は、即座にサービス・モデルに反映されます。ただし、RSMでもプロセス・モデルを開いている間にWBMが加える変更は、そのモデルが閉じられて再度開かれるまで、ビジネス・サービス・モデルには反映されないことに注意してください。

この繰り返し変換は、ほとんどパフォーマンスに影響しません。これは、ごく普通のRSAモデルをロードする場合と同様、XMIファイルがRSAにロードされている時に行われるためです。WBMビジネス・プロセス・モデルのロードとUML2ビジネス・サービス・モデルへの変換を1ステップで行うためには、カスタムのEMF XMIResource(www.eclipse.org/emfを参照してください)が使われます。これを利用すると、何ら製品間の依存関係を導入することなく、WBMとRSAの統合を完了することができます。これらは実際に、様々なバージョンのEclipseや様々なワークベンチ、様々なワークスペースで実行します。


RSAでBSMを使う

これでWBMビジネス・プロセス・モデルから変換されたビジネス・サービス・モデルは、単なるRSMモデルとして使うことができます。モデルをナビゲートするためには、モデル・エクスプローラーを使います。設計モデルの中でダイアグラムを作成し(WBMモデルは読み取り専用なので、WBMモデルの中で直接作ることはできません)、サービス・モデルのビューを好きな方法で示すことができます。例えば、WBMはクラス図をサポートしていませんが、WBMモデル上ではRSAを使ってクラス図を作成することができます(モデル要素をクラス図または自由形式の図の上にドラッグ・アンド・ドロップすることで、あるいはトピック図を作成することで作成できます)。ブラウズ・ダイヤグラムでWBMモデルを視覚化することができます。モデルの比較を使うと、2つのWBMビジネス・プロセス・モデルのUML変換、あるいは同じモデルに対する2つのバージョンのUML変換を比較することができます。また、他のRSAモデルでできることはすべて、つまりビジネス・アイテムのサブクラスの作成や、コラボレーションの実現、関連付けの追加、他のモデルとの統合、RequisitePro要求の付加など、何でも可能です。

WBMモデルへの参照を持つRSAモデルを保存する場合、その参照は、ビジネス・サービス・モデルでのモデル要素へのクロス・リソース参照として保存されます。しかしこのモデルはWBMビジネス・プロセス・モデルから変換された仮想モデルであるため、別リソースとしては保存されません。では、こうした参照はどうなるのでしょう。参照は壊れてしまうのでしょうか。実際には、クロス・モデル参照は、RSAモデル間での他の参照と全く同じように処理されるのです。RSA実装モデル(この例ではIAADemo Design.emx)を開き、モデル内容のナビゲートを開始します。別モデルへの参照に突き当たると、それがWBMモデルであれ別のRSAモデルであれ、その別モデルが即座に自動的に開きます。それがWBMモデルの場合は、ここでもUML2への変換は自動的に行われ、プロセス・モデルがロードされリンクが解決されるに従って、ビジネス・サービス・モデルが再度作られます。

また、RSAモデルからWBMモデル要素へのRequisiteProリンクも作成することができます。こうしたリンクは、クロス・モデル・リンクの場合と同じような方法で解決されます。URLコメントを作成してビジネス・サービス・モデルの要素に付加し、ビジネス要求を記述した補助文書を見つけやすくすることもできます。


UML2ビジネス・サービス・モデルとしてのWBMビジネス・プロセス・モデル

では、ビジネス・プロセス・モデルからサービス仕様を作成する方法を理解するために、変換されたビジネス・サービス・モデルの内容を、例を参照しながら調べてみましょう。

パッケージ

UML2ビジネス・サービス・モデルのパッケージ構造は(図8)は、WBMのカタログ構造と全く同じです。これをRSAのモデル・エクスプローラーで見ると、WBMのプロジェクト・ツリーと非常によく似ています。

図8. IAADemoのBSM
図8. IAADemoのBSM

データ・モデル

RootInformationModelを拡張すると、WBMモデルの中にあったBusinessアイテムとData StructuresがUMLモデルのクラスとして見えます。こうしたステレオタイプは、RUP Business Modelingプロファイルで規定されています(このプロファイルは、開かれると自動的にビジネス・サービス・モデルに適用されます)。図9を見ると分かる通り、ClaimFolderクラスは、図3のビジネス・プロセス・モデルで持っていた属性と同じ属性を持っています。

図9. ClaimFolderの«BusinessEntity»クラス
図9. ClaimFolderの«BusinessEntity»クラス

WBMではクラス図をサポートしていません。しかしRSAではクラス図を作成することができ、クラスやスーパークラスを示すことができます。WBMでのビジネス・アイテム・テンプレートは共有されたプロパティーを表すため、BSMではスーパークラスと見なされます。図10では、DataStructure TemplateはClaimContainerとClaimFolderの両方のスーパークラスであり、両方のサブクラスに共通なプロパティーを表します。UML2ではテンプレートは別の意味を持っており、インスタンス化可能なパターンをとらえるために使用します。WBMは、ビジネス・パターンに関してはテンプレートをサポートしていません。しかし、WBMビジネス・プロセス・モデルから派生したサービス仕様コラボレーションはパターンとして扱うことができ、別のCollaborationUsesを使ってインスタンス化することができます。また逆に、こうしたコラボレーションは、様々なビジネス・パターンをモデル化するための契約テンプレートに変換することができます。

図10. ビジネス実体のサンプル
図10. ビジネス実体のサンプル

複合型を持つ属性を、プロパティーまたは関連付けとして表示するように選択したことに注意してください。ClaimContainerには、非基本型のプロパティーとして示される、CoveringInsurancePolicyというプロパティーがあります。ClaimContainerは、ClaimFolderという別のプロパティーを持っています。このプロパティーも非基本型ですが、関連付けとして示されています。この2つの表記方式によって、同じ情報を異なる方法で見ることができます。ビジネス情報を整理し、表示するようなクラス図を、(別々な利害関係者のために複数のビューを持つようなものを含め)自由に作成することができるのです。特に、各サービス用に交換されるデータのために、別々なクラス図を作ることもできます。

サービス仕様

ビジネス・プロセス・モデルは、ビジネス機能要求を実現する、検証されたビジネス・オペレーションを表すものです。プロセスは、ビジネス目的を満足するために何をすべきかを規定します。この例では、プロセス・モデル中の一部タスクやプロセスを実装するシステム・ソリューションを、オブジェクト技術を使って作成することに決めました。それを作成する前に、ソリューション実装が満足すべき契約を規定する、ビジネス・サービス・モデルを持っている必要があります。こうした契約は、UML2のコラボレーションに基づいています。

WBMモデルの中の各ビジネス・プロセスは、Administer Claimプロセスを示した図11に示すように、UML2での同じ名前を持つコラボレーションとして見ることができます。このコラボレーションは、ビジネス要求を満足するために実装者が何をすべきかを規定した、ビジネス・サービス仕様、または契約を表します。コラボレーションは、参加者は誰か、彼らの責任は何か、そして彼らはどのように相互作用すべきか、を規定します。コラボレーション・ロール(コラボレーションのプロパティー)は、プロセス・モデルのタスクに割り当てられたロール・リソースから派生します。ロール名は、プロセス中の任意タスクに対して要求される最初のロール・リソースと同じです。ロール・タイプは、下記に説明するロールに対応するインターフェースです。コラボレーション・ロールは、何らかの結果を達成するために特定なコラボレーションの中で一つのロールを果たす、サービス・プロバイダーの使い方を表します。コラボレーション・ロールのタイプは、サービス・プロバイダーがそのロールを果たすために提供すべき責任を規定します。コラボレーション・ロール・タイプは多くの場合インターフェースであり、そのオペレーションは、そのロールの果たす責任に関しての仕様となっています。

図11. Administer Claim(請求管理)契約
図11. Administer Claim(請求管理)契約

ClaimContainerは、データ・プロバイダーとして動作するビジネス・アイテム・クラスです。つまりClaimContainerは、AdministerClaim契約が要求する情報を提供する責任を持ちます。ClaimContainerのデータ・アクセサー(accessor)機能は、ビジネス・プロセスの中のタスクが要求する可能性のある、データ変換または派生データを表します。WBMでは、これらはマップとしてモデル化されますが、UML2でのデータ・アイテム・クラスに対する単純なオペレーションとして見ることができます。Claim Processorビジネス・アクターは、ビジネス組織の中の人が果たすロールです。

契約の使用部分を判断するためには、コラボレーションに参加するものとして提供されるインターフェースと必要なインターフェースを、すべて知る必要があります。これらは、ビジネス・プロセス・モデルのタスクにリソースとして割り当てられたロールから派生します。そこで、完全なビジネス・プロセス・モデルを検証し、リソース・モデルの各ロールにどんなタスクが割り当てられているかを判断します。各ロールは、インターフェースとして見ることができます(図12のClaim Processorロール・リソースを見てください)。このビジネス・ワーカーの責任は、このロールがリソースとなっているタスクすべて(言い換えると、このロールに割り当てられた全タスク)です。他のロールは、モデル化されていないコラボレーションの、または不完全な契約の、参加者と見なされます。そのロールに割り当てられた各タスクに対して、ビジネス・ワーカー・インターフェースにはオペレーションが追加されます。このオペレーションのシグニチャーは、タスクの入力と出力から派生します。

図12. Claim Processorの責任
図12. Claim Processorの責任

実現契約は、アクティビティーとして示されています。アクティビティーはコラボレーションの振る舞いです。アクティビティーはビジネス・プロセスと同じ名前を持ち(従ってコラボレーションです)、ビジネス・プロセスから直接派生します(図13のAdminister Claimプロセスを見てください)。この契約の実装を開発する際には、その実装を実行すると、このアクティビティーによってパスが一致するようにする必要があります。契約は、これを実装がどう行うべきかは規定せず、何を行うべきかのみを規定します。

図13. Administer Claim実現契約
図13. Administer Claim実現契約

このアクティビティーには、ビジネス・プロセスの各入力と出力に対してInputPinとOutputPinがあります。こうしたpinの名前はビジネス・プロセスでの名前と同じですが、そのタイプは、プロセス・モデルのビジネス・アイテムから派生した«BusinessEntity»クラスです。例えば、Administer Claimアクティビティーには、ClaimContainerというタイプのclaimContainerという入力があり、同じタイプを持つclaimContainerという出力があります。

ビジネス・プロセス・モデルの各タスクは、新たに定義されたタスクの呼び出しか、他が提供するサービスの呼び出しか、あるいは別プロセスの呼び出しのいずれかです。タスクの呼び出しは、CallOperationActionで表現されます。CallOperationActionには、もう1つのターゲット、InputPinがあります。InputPinの名前はプロセス・モデルのタスクに割り当てられたロール・リソースの名前であり、またタイプは、そのロール・リソースに対応するインターフェースです。CallOperationActionのオペレーション・プロパティーは、ロール・インターフェースの、対応するオペレーションです。CallOperationActionはActivityPartitionの中にも置かれます。ActivityPartitionの名前はタスクに割り当てられたロール名と同じであり、Representsプロパティーは、ロール・インターフェースです。これによって、実現契約のアクティビティーのアクションに誰が責任を持つのかを示すことができます。例えば、Administer ClaimプロセスのContinue Claim Verification(請求検証継続)というタスクはCallOperationActionになり、その名前はContinue Claim Verificationです。このアクションには、パラメーターそれぞれに対してInputpinとOutputpinがあり、また、そのタスクに責任を持つロールである、ClaimProcessorというタイプのclaimProcessorという追加のターゲットInputpinがあります。このアクションはアクティビティー・パーティションに置かれませす。このパーティションの名前はclaimProcessorであり、RepresentsプロパティーはClaimProcessorインターフェースです。

プロセス・モデルでのプロセス呼び出しは、CallBehaviorActionで表現します。こうしたアクションは、他のコラボレーションの振る舞いを呼び出します。CallBehaviorActionに対する追加のターゲットInputPinはありません。これは、プロセス呼び出しは、どのロールにも割り当てられないためです。従ってこうしたアクションは、どのアクティビティー・パーティションにも割り当てられません。CallBehaviorAction Validate Coverageは、Administer Claimアクティビティーでのプロセス呼び出しの一例です。

WBMモデルでのタスクも、何らかの外部サービスの呼び出しを表します。WBMサービスには、ロール・リソースを割り当てる必要があります。そうするとこのロール・リソースは、そのサービスを提供することに責任を持つグループと見なされます。各WBMサービスはインターフェースのオペレーションに対応し、その名前はそのサービスに割り当てられたロール・リソースの名前です。これは、何らかのサービス・コンポーネントが提供するインターフェースを表現します(このコンポーネントは、このインターフェースをUML実装モデルで実現します。そうするとWBMサービス呼び出しは、(ちょうどタスク呼び出しと同じように)実現契約アクティビティーのCallOperationActionになります。このCallOperationActionのターゲットInputPinも、サービス・プロバイダーを表すWBMサービスに割り当てられたロール・リソースから派生します。Administer Claimアクティビティーには、Validate Creditに対する1つのサービス呼び出しが含まれています。

実現契約アクティビティーの、他のモデル要素は、ビジネス・プロセス・モデルの対応モデル要素から直接派生します。この詳細は、BPMからBSMへのマッピングで説明します。


ビジネス・ユースケース

各ビジネス・プロセスは、対応する«BusinessUseCase»ユースケースも持っています。通常こうしたビジネス・ユースケースは、ビジネス・ゴールと目的を満足するためのビジネス要求を表現するために使われ、コラボレーション契約と、その契約が実現するRequisiteProでの要求とをリンクします。またこのユースケースは、例えばビジネス・プロセスでのステップを要約するために、あるいはサービス品質実装が満足すべき非機能要求をリストアップするための場としても使われます。ユースケース文書には、ビジネス・プロセスの記述が含まれています。«BusinessActor»は、ビジネス・プロセスの参加者を示すために使われます。これらは、ビジネス・プロセスのタスクに割り当てられたロール・リソースです。各«BusinessActor»アクターは対応する«BusinessWorker»インターフェースを実現し、アクターの責務を示します。

またダイアグラムを作ることによって、各ビジネス・プロセス用に作られたビジネス・ユースケースや、ユースケースに参加するアクター、ビジネス・ユースケースの実現契約を規定するコラボレーション、そしてビジネス機能を規定するためにコラボレーションを行うロール、などを示すこともできます。例えば図14では、AdministerClaimプロセスはアクターになり、ユースケースになり、コラボレーションを実現しています。このビジネス・ユースケースに少し手を加えるために、URLコメントを追加し、ワードプロセッサーなどの手段を使って、ユースケースの詳細(例えばRequisitePro)を埋めます。RequisiteProはユースケースとドキュメントを関連付けることができ、また追加要求や両者の間のリンクを管理することもできます。

図14. Administer Claimビジネス・ユースケース
図14. Administer Claimビジネス・ユースケース

BPMからBSMへのマッピング

このセクションでは、ビジネス・プロセス・モデルと、それに対応するUML2でのBSMとの上位レベルでのマッピングを要約します。各マッピングは論理的に記述しています。また、このマッピングがWBMとRSMとの統合であることを示す補足として、必要に応じて情報を追加しています。ある場合では、実際のWBMあるいはUML2メタクラスがマッピングとしてリストされています。また、メタクラスでは意味が曖昧になる恐れのある場合には、概念間でのマッピングを示しています。UML2では、一部のビジネス・プロセス要素は、(完全な契約を規定するための)数多くのモデル要素と見なされます。

ビジネス・プロセス・モデルからビジネス・サービス・モデルへのマッピング
BPM要素マッピングの詳細UML要素
ビジネス・モデリング・プロジェクト

WBMの最上位レベル構造は、ビジネス・モデリング・プロジェクトであり、resources.XMIというファイルを含んでいます(このファイルは、下記のモデルの全要素を管理するためのコンテナーです)。これはRSMでのプロジェクトと同じであり、ビジネス契約モデルに対応します。ビジネス契約モデルは、RUPのビジネス・モデリングのプロファイルを適用したRSMモデルです。

RSAは、ルート・コンテナー・ビジネス・プロセス・モデルに対応するプロジェクト・リソースを直接開くことができます。RSAを使ってresources.XMIファイルを開くと、WBMビジネス・プロセス・モデルはBSMとして表示され、ビジネス要求と、(契約を実現する)実装との契約を表現します。BSMはビジネス・ユースケース・モデルとビジネス分析モデルとしてステレオタイプ化されます。これはBSMがビジネス要求を満足するための契約を規定することを示しています。


同じプロジェクト。またresources.XMI を開く際にはUML2のBSM。
データ・カタログ、プロセス・カタログ、組織カタログ、種別カタログ

WBMカタログは型付けされ、特定なモデル要素しか含んでいません。WBMカタログに対応するUML2パッケージには、この制限はありませんが、UMLモデルの構成は、WBMモデルの構成と同じです。こうしたパッケージの多くは、WBMプロジェクト・エクスプローラーでは見えませんが、確かにあり、BSMでは見ることができます。

パッケージ

プロセス

ビジネス・モデルに対するRUPの手法では、プロセスの「ブラックボックス(外部)」ビューと「ホワイトボックス(内部)」ビューを明確に分けています。外部ビューはユースケースが提供し、内部ビューは、1つ以上のユースケースの実現が提供します。

BSMはRUPを改善したものであり、要求、分析、設計の推敲のステップ間の関係を正式化します。BSMでは、ビジネス・ユースケースは何らかのビジネス・ゴールと目的を表します。するとこうした要求は、ビジネス・プロセスに対応する契約によって実現されます(この契約は、実装が何をすべきかは規定しますが、いかにすべきかは規定しません)。つまりBSMは、ビジネス要求や、ITシステムでの実現方法の仕様(仕様、契約、あるいはブラックボックス)ビューと、実現(実装や契約実現、あるいはホワイトボックス)ビューとを、正式に分離するのです。

BSMモデルはプロセスを、参加するロールやその責任、ビジネス要求を満足するために必要な相互作用のオーケストレーションなどを記述する契約として扱います。このプロセスは、ビジネス・ユースケースを実現するRUPのビジネス・ユースケースの実現(コラボレーション)であると同時にアクティビティーでもあるとして扱われます。このコラボレーションは、実装者が実現すべき契約を規定します。この契約には、(提供されるインターフェースと、要求されるインターフェースによる)使用契約と、(コラボレーションの振る舞いを規定するアクティビティーによる)実現契約の両方が含まれます。このアクティビティーは、参加するロールが契約を満足すべく責任を果たす際に、どのように相互作用すべきかを定めるプロトコルを規定します。このアクティビティーは、下記に示すようにプロセスから直接派生します。


ビジネス・ユースケースと
ビジネス・ユースケースの実現契約

実現契約

役割(ロール)

プロセスの中のタスクには、そのタスクの実行に責任を持つロールが割り当てられるかも知れません。ビジネス・プロセス・モデルはビジネスに関するものであり、ビジネスをサポートする自動システムに関するものではないため、WBMモデルは、プロセスの外部ビューと内部ビューの両方を表現します。従って、RUP手法を使ったビジネス・モデリングでの場合と同様、外部ロールと内部ロールを区別しません。

ビジネス・プロセス・モデルの中で、何らかのタスクを実行する、あるいは何らかのビューを提供する各ロールは、コラボレーションに参加するロールの責任を定義する«BusinessActor»とインターフェースを表現します。(任意のプロセスでの)ロールが実行する各タスクは、ロールのインターフェースのオペレーションにマップされます。アクターとインターフェースの名前は、ロールの名前から直接派生します。

またロールは、コラボレーションに振る舞いとして付加されたアクティビティーのActivityPartitionとして見ることもできます。このロールに割り当てられたタスクの呼び出しを表現するCallOperationActionsはすべて、対応するActivityPartitionに置かれます。このパーティションの名前は、プロセス・モデルの中のロール名と同じです。ActivityPartitionのRepresentsプロパティーは、そのロール・タイプに対応するインターフェースに設定されます。


ビジネス・アクター

ロール

リソース定義とリソース

リソースは通常、タスクを完了するために必要な何か、あるいはタスク期間中に使用される何かのいずれかを表します。プロセス・モデルのIndividual Resourceタイプ定義とBulk Resourceタイプ定義は、BSMのクラスとして表現されますが、特定なリソースは、こうしたクラスのインスタンス(InstanceSpecification)で表現されます。


クラスとInstanceSpecification

リポジトリー

プロセス・モデルでのリポジトリーは、プロセスやタスク間で共有可能なアイテムである、Business Itemのストアを表します。アクティビティーの中のDataStoreNodeは同じ概念をUMLでモデル化するために使われます。UML2のDataStoreNodeはTypedElementであり、それを含むアクティビティーの中に見えます。従って、グローバルで再利用可能なリポジトリー参照を直接表すことはできません。BSMでは、WBMのグローバルRepositoryはInstanceSpecificationにマップされ、DataStoreNodeはこのInstanceSpecificationをターゲットとする依存関係を持っています。この問題はOMG UML2 RTFに提起されています。


DataStoreNodeとInstanceSpecification

タスク呼び出し

グローバル・タスク呼び出し

タスクは、プロセスの中で実行され、それ以上モデル化できない何らかの作業単位を表します。プロセスはロールが実行するタスクを連結したシーケンスであり、生成されるリソースや利用されるリソースを含んでいるかも知れません。

あるロールに割り当てられた各タスクは、そのロールが、そのタスクを実行する上での責任を表します。こうした責任は、あるロールに対応するロール・インターフェースのオペレーションとして収集され、またオペレーションと見なされます。

プロセスの中のタスク呼び出しはアクティビティーの中のCallOperationActionで表現され、そのタスクを実行することに責任を持つロールから派生した、そのインターフェースで対応するオペレーションを呼び出します。

ロール・インターフェースでのオペレーションの名前は、タスクの名前から直接派生します。例えばOffer Reservationタスクは、Customer Service Systemインターフェースの責任であり、実現契約を表すアクティビティーのCallOperationActionを使って呼び出されます。

またロールによって、各CallOperationActionにはターゲットとしてさらにInputPinが追加され、そのロールに割り当てられたタスクを呼び出します。このInputPinは、そのタスクを実行するロール・インスタンスを提供するために使われます。


ロール・インターフェース

CallOperationAction

プロセスの呼び出し

別プロセスの呼び出しは、呼び出されたプロセスを表すアクティビティーを呼び出すCallBehaviorActionとして表現されます。プロセスはロールには割り当てられません。従って、追加のターゲットInputPinはありません。


CallBehaviorAction

サービスの呼び出し

サービスの呼び出しは、タスクの呼び出しと似ています。サービスに割り当てられたロール・リソースは、そのサービスのプロバイダーと見なされます。このロールに対するCallOperationActionのターゲットとして、InputPinが追加されます。


CallOperationAction

コネクション

タスクとプロセス呼び出しとの間のコネクションは、コントロールとデータのフローを表します。これはプロセス中のアクション・シーケンスを規定し、またタスクを実行するロール間の相互作用ルールを規定します。BSMでは、こうしたフローをコントロール・フローまたはデータ・フローとして扱います(これらのフローは、同じプロセス・ルールを表現するためにアクティビティーの中のアクションを接続します)。


コントロール・フローまたはオブジェクト・フロー

ビジネス・アイテム

WBMでのビジネス・アイテムは、プロセスのタスク間を流れる情報の要素を表します。そうした情報の要素は、物理的な成果物(レポートやフォーム)の場合もあれば、電子的な成果物(eメールや電子文書)の場合もあり、また物理的な「もの」の場合もあります。こうしたビジネス・アイテムは、BSMではクラスとして表現されます。WBMビジネス・プロセス・モデルでのビジネス実体は、UMLのビジネス・ドメイン・モデルでの永続クラスに対応する場合もあれば、対応しない場合もあります。通常、こうしたビジネス実体は、モデル中のタスクやプロセス間で交換されるデータやメッセージを定義する、データ転送オブジェクトに対応します。こうしたデータ転送オブジェクトは多くの場合、ドメイン・モデルでのビューであり、その契約を実現する分析モデルで規定されます。


ビジネス・アイテム・クラス

通知(Notification)

通知は、(通常は非同期の)通信であり、プロセスに何らかのイベントが発生したこと、あるいは、何らかのビジネス・アイテムの状態が変化したことを示します。BSMでは、通知は«BusinessEvent»として扱われます。


ビジネス・イベント

開始/終了

これらのノードは、ビジネス・プロセス・モデルにおいても、実現契約を表すBSMアクティビティーにおいても、プロセスの開始と終了を示します。


初期ノード(InitialNode)/
終了ノード(ActivityFinalNode)

デシジョン/マージ

BSMアクティビティーでのビジネス・プロセス・モデルのデシジョン・ノードとマージ・ノードの表現は似ています。


デシジョン・ノード(DecisionNode)/
マージ・ノード(MergeNode)

フォーク/ジョイン

プロセス・モデルは、並列アクティビティーの実行開始を表すフォーク・ノードと、こうした並列アクティビティーの同期点を示すジョン・ノードを含むことができます。BSMアクティビティーでの両者の表現は似ています。


フォーク・ノード(ForkNode)/
ジョイン・ノード(JoinNode)

ループ

WBMモデルには、3つのループ構成体(WhileループとDoループ、Forループ)があります。BSMアクティビティーでは、これらはすべてLoopNodeと見なされます。(RSMでは、現在LoopNodeをサポートしていません。)


ループ・ノード(LoopNode)

通知ブロードキャスター(Notification Broadcaster)

通知をブロードキャストする場合、WBMモデルにはNotification Broadcasterモデル要素があります。この要素は、送信中であるという通知を表します。BSMアクティビティー・モデルでは、これらの通知をBroadcastSignalActionと見なします。(RSMでは、現在BroadcastSignalActionをサポートしていません。)


BroadcastSignalAction

ロケーション

WBMモデルでのロケーションとロケーション定義は、組織モデルの一部として、地理的なロケーションを表します。BSMでは、プロセス・モデルでの各ロケーション定義は、クラスと見なされます。ロケーション定義のインスタンスである各ロケーションは、そのロケーション定義に対応するクラスのInstanceSpecificationと見なすことができます。

Class/InstanceSpecification
ルール

WBMモデルでは、幾つかの要素にルールを付加することができます。ただし、これが主に使われるのは、データ定義のための整合ルールを定義するビジネス・アイテム・カタログの中です。BSMでは、こうしたルールは«BusinessRule» 制約と見なされます。


ビジネス・ルール

まとめ

ビジネス・プロセス・モデルとオブジェクト・モデルとを統合することによって、ビジネスの概念を、デプロイされるアプリケーションに変換することが非常に容易になります。そうした統合の特徴として、下記を挙げることができます。

  • 開発ライフサイクルの初期から、また頻繁に、要求に対する検証を容易に行えるようになる
  • 開発プロセスにおけるコミュニケーションの精度やフィードバックを高めることができる
  • システムが、変化するビジネス要求に確実に対応でき、デプロイ前に陳腐化することがなくなる
  • 開発者が変更の効果を容易に判断でき、また変更を容易に追跡できる
  • 最も豊富なビジネス知識を持ち、そしてビジネス価値を提供することに責任を持つ、主要なビジネス利害関係者の協力を仰ぐことができる

契約ベースの開発によって、ビジネス・アナリストも開発者も、ビジネス・プロセス・モデルとオブジェクト・モデルの両方の良いところを最大限に利用することができます。そしてビジネス要求をとらえ、そうした要求を、ハイパフォーマンスで維持管理容易な、オブジェクト指向でサービス指向の実装に変換することができます。

参考文献

学ぶために

  • RUP Plug-In for WBI Modelerを利用すると、UML2を拡張してBusiness Contract Modelを扱えるようになります。
  • ビジネス駆動型開発は、ビジネス・アプリケーションを開発するための手法です。この手法の主な焦点は、ビジネス・ゴールと目的を明確に理解すること、またそれらを満足するためのプロセスやサービス、デプロイされたアプリケーションなどの分析に関わるロールやアクティビティー、そして作業成果を理解することです。ビジネス駆動型開発はソリューションを完全なものとするために、アプリケーションを監視してKPIに関するデータを収集し、ITソリューションが意図したビジネス・ゴールと目的を満足することを検証し、またビジネス進化のための堅固な基礎を提供することによって、コストを削減し、価値を高めます。
  • WebSphere Business Modelerを利用することによって、ビジネス・アナリストはビジネス・プロセス・モデルを容易に作成し、シミュレートし、そして変化させることができ、ビジネス・ゴールと目的が満足されることを確認することができます。
  • IBM Rational Software Architect product pageには、技術資料やハウ・ツー記事、教育資料、ダウンロード、Rational Software Architectに関する製品情報などの他、豊富な情報が用意されています。

製品や技術を入手するために

  • ここからはじめる Rational Software Architectは、Rational Software Architectを試用する際にご利用ください。Business Contract Modelを見るためのツールや、様々なアーキテクチャー・スタイルに対する実装コードを生成するサービス実現モデルのための開発ツールが用意されています。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational, Architecture
ArticleID=277501
ArticleTitle=ビジネス・サービス・モデリング
publish-date=12272005