 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||
|
||||||||||||||||
| SOA的なアプローチにおけるARISの活用 | ||||||||||||||||
|
さて、システム開発アプローチとしては、大きく下記の3つがあるかと思います。 |
||||||||||||||||
表2：システム開発のアプローチ |
||||||||||||||||
| DOAとOOAに関しては、詳細な解説書などが出版されているため、詳しい解説は控えます。 最近のシステム開発アプローチは、OOAによるアプローチが大半を占めてきていると感じています。画面開発やロジック開発は、OMG（Object Management Group）が提唱するUMLを用いて設計されるケースが多いようです。クラス図を用いて機能・情報をオブジェクトとして構造化し、且つアクティビティ図やシーケンス図を用いてプログラムフローをモデル化することでソフトウェア部品を製造（プログラミング）しているかと思います。また、ソフトウェア部品の細分化は、更に進み、画面を構成する部品、画面の動きを制御する部品、データー・アクセスのための部品及びデータを用いて処理を行うビジネスロジック部品という単位で分類されています。 また、開発現場では、RDB（Relational Data Base）を使用することが多いため、DBスキーマ製造のために、依然としてDOAによるDB論理／物理設計が行われているようです。 これらのことから、ソフトウェア機能開発やDB設計を行うためには、プロセス・モデルのから、オブジェクトとして構造化するためのクラス要素やデータベース・スキーマを設計するためのエンティティ要素を抽出することが重要となってきます。 では、最近注目を浴びているSOA的なアプローチを考えてみます。SOAとは、図4に示すようにシステム機能を業務単位でまとめたサービスとして捉え、更に図5に示すようにそれらサービスを業務の流れに即して呼び出して利用するという定義です。そして、この業務の流れに即してシステム機能を利用するという概念は、まさにプロセス指向アプローチと呼ぶことができます。  図4：オブジェクトの捉え方とサービスの捉え方 （画像をクリックすると別ウィンドウに拡大図を表示します）  図5：機能指向とプロセス指向 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||||||
| ここで重要なことは、図5に示すようにサービスとサービスをメッセージによって疎結合することによって、ビジネス・プロセス変更時に、システム機能としてのサービスを柔軟に組み替えることができるシステム環境を構築することです。このサービス間のメッセージのやり取りを記述したプロセス・モデルの記述方法としては、BPMI（Business Process Management Initiative）が提唱するBPMN（Business Process Modeling Notation）があります。このBPMNのプロセス・モデル化の記述方法は、本質的にeEPCと同じと言えます。 BPMIが提唱する砂時計モデル（http://www.bpmi.org/）には、「BPMNで記述したビジネス・プロセスは、BPEL（Business Process Executable Language）に変換され、実装されていく」と記述されています。このBPELで開発されるITシステムは、「システムの機能と機能をWeb サービスとして呼び出し、それらを繋ぐ」ことによって、ユーザにサービスを提供します。 このシステムの機能と機能を繋ぐシステムをEAI、Process Engine、Enterprise Service Busなどと呼びます。 では、ARISで記述されたビジネス・プロセス・モデルの定義は、どのようにBPEL開発環境に渡されるのでしょうか？ 実はP2Aに位置するARIS製品群が明確にあるのかというと、単一製品という形では存在していません。P2Aという技術は、ARIS Design Platformに位置する製品群が他のモデリング・ツール、もしくは、システム開発ツールと連携するために開発されたインターフェースとして実装されています。このP2Aを利用して、ビジネス・プロセスに沿ったSOA環境を実現するという試みが、欧米では盛んに行われています。 実際には、図6及び図7に示すようにARISでeEPC／BPMNモデルもしくは、BPELモデル（現在、開発中）を記述し、それらの定義情報をBPEL開発プラットフォーム（例えば、BEA社のWeb Logic WorkshopやSAP社のExchange Infrastructureなど）に引き渡して開発を行うという試みです。  図6：モデルの定義  図7：システム開発におけるARISモデル領域 （画像をクリックすると別ウィンドウに拡大図を表示します）  図8：SOA的アプローチのモデリング作業 （画像をクリックすると別ウィンドウに拡大図を表示します） ここで、ビジネス・プロセスの視点から必要とするシステム機能がWebサービス・リポジトリにない場合は、前述したように新規に業務パッケージを採用したり、スクラッチからUMLなどを用いて新規機能開発を行います。そして、その新規に開発された機能も、新しいWebサービスとしてWSDLファイルを記述し、Webサービス・リポジトリに登録されます。 次の作業としては、ビジネス・プロセスであるeEPCを参考にして、システム連携プロセスであるBPELモデル（現在、開発中です）を記述します。そして、そのBPELモデルに既に規定してあるWebサービスを配置していきます。 このBPELモデル定義をBPELフォーマットのファイルとして抽出し、BPEL開発ツールに引渡し、プロセス・エンジンの開発が行われていくこととなります。 余談ですが、先日、BPMIとOMGが、BPM領域において標準化活動を共同で行う旨の緊急発表を行いました。これは、図8に示すシステム開発アプローチを実現するための標準化共同活動が本格化してきたと感じさせます。 |
||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
