« 喜んでやがて悲しき日本サッカー | メイン | 秋の富士 »

ビジネスコンポーネント指向開発(10)

ソフトウエア工学的な開発手法との対比

久しぶりに開発技法の話です。

この「ビジネスコンポーネント指向開発」の技法は世間的には何という名前なのだろうか。いわゆるソフトウエア工学では、従来の構造化分析、構造化プログラミングといった構造化手法からいまはオブジェクト指向というふうに変わってきていると書いてある。

構造化技法というのはDFDを書いて、プログラムを関数という「部品」に分割して、それを組み合わせてソフトウエアをつくると言われてもだいたいわかるが、オブジェクト指向はよくわからない。オブジェクト指向で、「データ」と、それを操作するための「メソッド」の組み合わせて、それをカプセル化したものが「オブジェクト」ですと言われても、これって構造化手法のこととどこが違うのと思ってしまう。

一方、オブジェクト指向はプログラミングから来ているから、分析とか業務設計には向いていないとも言われている。DOAをやっている人がよく言う。確かにUMLでビジネスを書かれても、特にユーザは理解できない。ユーザに理解してもらえない手法は、システム屋のマスターベーションでしかない。だからといって、DOAのER図がユーザから理解されるかというとこれもなかなかむずかしい。

DOA(Data Oriented Approach)というのは、和製英語で堀内一さんが最初に言い出したものでが、それまでのPOA(Process Oriented Approach)というものは今はどうなっているのだろうか。

こうしてみると開発手法は、構造化手法、オブジェクト指向、DOA、POAとあるが、これだという決定打はないように思える。いまは、オブジェクト指向ばかりのように見えるが、それだけで満足できるものができるかどうかあやしい。筆者は、それぞれの手法を適材適所的に使うことを提案したい。言い換えれば、それを実行しているのが、「ビジネスコンポーネント指向開発」なのである。

システムは(ビジネスといってもいい)、再三言ってきたように機能とプロセスとデータから成り立っている。これらを設計するのに、基本的に機能はOOA(Object Oriented Approach)、プロセスはPOA、データはDOA、全体を「構造化」するという考え方である。ここでいう「構造化」というのは、構造化手法ということではなく(いわゆる構造化手法というのは、POAやOOAに引き継がれている)、SOAの概念で柔軟な構造にするという意味です。

ここで注意しなくてはいけないのは、全く別々にやるわけではなく、主としてその手法を用いるといった程度のものである。逆に共通するもの、あるいは交差するものもある。

例えば、機能といった場合、いまオブジェクト指向で言う「オブジェクト」という概念をあてはめているが、POAでは「アクティビティ」であり、DOAでは「エンティrティ」に相当する。だからそこでお互いが結ばれていくというイメージです。もう少し説明を加えると、OOAで実ビジネスおける概念をしっかり定義することであり、そこから生まれたアクティビティ(コンポーネント)をPOAでシンプルなプロセスにし、DOAでリソースデータを中心にしたデータインフラを構築するというのが正しい方向である気がします。

この考え方を「ビジネスコンポーネント指向開発」において具体的に説明すると、まず「オブジェクト」を書類というふうに定義しています。ビジネスではほとんどの場合、書類の受渡し(紙ではなくても)により仕事をしています。だれかに依頼され、それを処理して、つぎに渡すという流れですが、それは書類という「オブジェクト」を作成し、できたものが「クラス」と言ってもいいかもしれませんが、その書類が転記されていくことが処理に当たると考えています。

この「クラス」が、「アクティビティ」となってBPMに飛んでくるわけです。BPMではPOAに考え方によりプロセス中心に構築していきます。「ビジネスコンポーネント指向開発」では単なる「アクティビティ」ではないもう少し、広いサービスのようなものも対象にしますから、それらもひっくるめて「ビジネスコンポーネント」と呼んでいるのです。

次に、データとの関係を見て行きましょう。DOAでは、ER図を書くことでデータとプロセスが表現できることになっています。DOAでは、まずリソースデータとイベントデータに分けて設計します。リソースデータは、人・物・顧客などの、いわゆるマスタデータで、イベントデータは、「○○する」という言い方ができる、例えば、受注、出荷、購買といったものがこれにあたります。そのイベントデータは時系列的においていきますから、プロセスを表現していることになります。

とういうことは、それでプロセス設計ができるじゃないかと言われますが、なかなか分かりにくく、ユーザには難しいのです。従って、DOAでリソースデータベースの設計を行ない、BPM側はそのリソースデータを使ってプロセスを回し、そこで発生したイベントデータはBPM側で作るというのがいいのではないだろうか。

このデータベースの設計と蓄積されたデータの活用も含めたデータベースマネージメントについては次回に提示する。
 

トラックバック

このエントリーのトラックバックURL:
http://kamawada.com/~masanori/blog/mt/mt-tb.cgi/357

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2007年10月19日 10:30に投稿されたエントリーのページです。

ひとつ前の投稿は「喜んでやがて悲しき日本サッカー」です。

次の投稿は「秋の富士」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type