» 【第23号】DOAとOOAの相違点

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第23号】DOAとOOAの相違点

DRI通信23号 「DOAとOOAの相違点」    1998.8.1
長引く梅雨、不景気、冷めたピザ凡人小渕新総裁、竹内靖雄著「「日本」の
終わり」(日本経済新聞社)など明るい話題の少ないこの頃ですが、皆様い
かがお過ごしですか。今月はまたDOAとOOAの関係について考えて見た
いと思います。
日経コンピュータ7月6日号に、PRとしてですが世界最大のオブジェクト
指向・Javaプロジェクトとして「IBMサンフランシスコ」が紹介されてい
ます。日本では東京国際大学の堀内一教授や佐藤英人教授らがCBOPとし
て共用ビジネスオブジェクト開発のプロジェクトを推進しておられます(第
2回七夕会で紹介)。
一方、日経コンピュータ4月13日号にR. G. Fichmanらによる「オブジェ
クト指向技術導入失敗の研究」、あるいは6月22号にS. Lauesenによる
「ビジネスアプリケーションにオブジェクト指向は不向き」の記事が紹介さ
れ、またDatabase Newsletter 1998 Jan/FebではR. Rossが”Boochらの
コンポーネントとconnectできない”と言っています。


われわれはDOAを啓蒙・推進しているため、しばしばOOAについてコメ
ントを求められます。OOAといっても人の数ほどいろいろあるようで、目
下上記のような記事を参照して回答せざるを得ない状況ですが、やはりその
正体が気になります。「DOAを防衛するためでは」と勘繰る方もあります
が、「DOAとOOAとどちらが正解か」などは、われわれの力の及ばない
ところで決まって参ります。私は純技術的ないし学問的な観点から考えてい
るつもりです。
そんな動機から、なるべくDOAとOOAの双方に詳しい方に参加していた
だいて、議論の機会を持っているわけですが、なかなか噛み合った議論がで
きません。そこで考えました。方法論は一般に次のような手順でつくられる
ものと思われますので、まずその前提から吟味していくべきではないかと。
   設計      適用
前提────→方法論────→結果
↑    (モデルと手順)   │
└───────────────┘
     改訂・評価
DOAの方法論のひとつ、我々のPLAN-DOA設計の前提は、おおよそ次の
ようなものと言えます。
(1)対象は業務アプリ(CASEツールを含む)
(2)共用DB中心のアーキテクチャ
(3)画面・帳票(Needs)ベース
(4)概念(Conceptual)と物理を峻別
(5)モデルによる分析(Analysis)
(6)組立図(Diagram)と部品表によるコミュニケーション
(7)リポジトリ(Repository)の活用
(1)は逆にいうと、PLAN-DOAではOS、DBMS、GUI、通信ソフト、WP、
LPなど基本ソフトおよび汎用アプリを除くことを意味します。OOAは必
ずこれらを含むようですからまず守備範囲が違っています。ところでOOA
ではDWHなどの情報系はどう扱うのでしょうか。
(2)はDOAの命とも言えるところです。図で書くと次のようになるでしょう。
                     ┌────┐      
                     ↓    │
                  ┌────┐ 加工PG
BU─→「入力IF」──入力PG─→│    ├──┘
                  │共用DB│
BUs←「出力IF」←─出力PG──│    │
                  └────┘
その特徴は次のようなものといえるでしょう。
・実務の世界に発生したデータはすべて(エンティティごとの)入力プロセ
スを通じ共用DBに反映される、たとえば受注だと
 [受注#]-(顧客#、品#、受注数、@、受注日、・・・)
に関するデータが反映される
・不特定多数のビジネスユーザ(BUs)の欲しいデータはすべて出力プロ
セスを通じこの共用DBから得られる
・このため加工データを導出する(加工データごとの)加工プログラム
(PG)が用意されている、たとえば
 受注金額=f(受注数*@)や、未引当残高=g(未引当残高、受注数)
におけるf、gの機能を持つ加工プログラムが用意される
・PGとPGは共用DBを介してコミュニケーションするため、論理的には
PG同士でメッセージなどをやりとりする必要はなく、個々のPGの機能は
非常に単純なものとなる(イントラネットにより社内組織がフラットになる
のと似ている)
・複雑な加工データ導出プロセスも(今機械効率は考えないものとし)適宜
中間加工データを共用データとして定義してやれば個々の機能はデータ定義
と見なせるような単純なものとなる
・入力PGはいくつかのパターンを用意すれば、また出力PGは出力インタ
ーフェース(IF)を規定すれば、汎用化/自動生成可能であり、加工PG
も限りなくデータ定義に近づけられるため、論理的に業務アプリとしてのプ
ログラムレス(業務ルールはすべてリポジトリにデータとして書かれるので、
これを業務プログラムとして書く必要がなくなる)がほぼ可能になる
OOAでもER図などを書いてデータ分析をするようですが、このような、万
人にオープンな共用DBが作られるのでしょうか。なにかデータはプログラ
ムの中にとりこまれて、共用されない印象を持つのですが。
(3)は、「情報システムが目的とする製品は、ビジネスの目的を達成するため
の画面・帳票である」との前提に基づき、画面・帳票の形式を固め(暫定を
含む)、これを構成するデータ項目を分析するアプローチをとります。この
とき同時にデータ項目(部品)から画面・帳票(製品)を組み立てる出力
PGの仕様が決まります。
OOAでは「直接実務の管理対象をオブジェクトとしてとらえるのだ」と言
われます。個人差なくこれをとらえる方法が難しいように思われるのですが。
(4)は、ビジネスユーザの情報要求の「本質」を捉えようとするものです。
情報処理の様相はITの進歩によって大きく様変わりますが、ビジネスユーザ
の情報要求の本質は、コンピュータ以前から、あるいは江戸時代からさほど
変わっていないと考えられます。ITこみでユーザ要件をとらえると、その本
質は変わっていないのに、ユーザ要件は変わって見えます。しかし逆に、特
に共用DBをIT独立の概念DBとすると、安定した情報資源を広範囲に流通
させ、大勢で共用・再利用することができるようになります。またユーザと
しては難しいITの言葉を耳にしなくて済みます。
OOAでは、「IT独立にユーザ要件を捉え、その分かりやすさと安定を図る
こと」、またアウトソース時代に向かって「ユーザ要件を実装独立に表現し
たいニーズ」をどのように扱っていくのでしょうか。
(5)のモデルによる分析は、科学的アプローチとしては当然の方向です。
PLAN-DOAでは「概念レベルでビジネスを表現するTHデータモデル」と
「業務プロセスを中核とするプロセスのモデル」が中心となります。OOA
の場合は方法論によって各種異なるようですが、それぞれこの方向にあると
いえるでしょう。
(6)はエンジニアリングで普遍的な個人差の出ない組立図をベースにコミュニ
ケーションしようというものです。目に見えにくい情報システムを見えるよ
うにしようというわけです。完成度は異なりますが、すべてこの方向にある
といってよいでしょう。
(7)はシステム開発・保守も一つの業務アプリと見立て、DB技術を適用しよ
うというものです。PLAN-DOAのリポジトリは(原則として)共用DBと
してユーザやプログラムからオープンにアクセスされます。この場合はメタ
データですから、たとえばDWHユーザが
 [データ項目ID]-(データ項目名、所属概念ファイルID、・・・)
から、データの所在を調べたりすることになります。
なお、PLAN-DOAでは、リポジトリは内容に応じて実装独立の概念リポジ
トリ、実装従属のソフトウエアリポジトリ、運用管理で使われるプラット
フォームリポジトリの3階層に分かれるべきとされます。
OOAでのリポジトリの構造はあまり公表されていないようで不詳です。
「メタデータもプログラムとカプセル化されるので公表の必要はない」とい
うことなのでしょうか。
以上総じて前提(1)、(2)、(3)、(4)、(7)は、PLAN-DOAとOOAとでかなり
違っているように思われます。これを手がかりにすれば噛み合った議論が始
められるのではないかと期待されますがいかがでしょうか。OOAに造詣の深
い皆様からのご意見お待ちします。