» 【第14号】DOAとOOA

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

DRI通信14号 「DOAとOOA]         1997.11.1
後半暑い日の多かった10月も、ここへきてぐっと冷えて参りました。10月
はコンサルは少なかったのですが、BIT社との提携に関する新聞発表、「概
念データモデル」の英訳レビュー、TIS社での講演「情報処理専業者におけ
るDOA」、ガートナーセミナー参加、Beacon97での講演「2010年の情
報処理ビジネスを占う」などに忙殺され、フル稼働(31日間7時間以上稼働)
となり、山の紅葉と温泉どころでなく、DB研(来年は2月18日)の準備も
5時間ほどできただけでした。
注)オブジェクト指向の世界では、OOAというとオブジェクト指向アナリシス
の意味になるとのことですが、ここではDOAと対比させてオブジェクト指向ア
プローチ(分析、設計、開発、保守)の意味で使わせてもらいます。
■意外に少ない反論
13号では「業務アプリにはOOAは不要ではないか」という大胆な仮説を提
案してみたのですが、意外に反論が少なく、OOAに詳しいと思われる方には、
催促のメールまで出したのですが、厳しい反論は頂けませんでした。ある人は
「日本人は与えられたアーキテクチャの上では議論するが、アーキテクチャを
変える議論はしない(してはいけないと思い込んでいる)のだよ」とのこと。
これでは、いつもアメリカの後を追いかけるだけになるのでは、と心配しまし
た。


それでも貴重な3件の反論を、東芝、日興システム、東ソーなどの皆様から頂
きました。結局、議論が噛み合わず結論を得るには至っていないのですが、な
ぜ議論が噛み合わないかを考えることによって、いろいろな収穫を得ることが
できました。
■原因
まず、次のような私のDOAでの前提が明示されてないことが原因のようです。
(1) ユーザの情報要求は画面・帳票であって、DBでもプログラムでもない
(OOAではプログラムを製品としているかに見えるところがある)。次の対比
である。
  製品=ユーザ要求 原料   製造手段
  画面・帳票    DB   プログラム
  自動車      部品   工作機械・治具
  料理       食材   なべ・コンロ
(2)ユーザの情報要求は実装独立(概念レベル)に存在する。設計順序は、ま
ず実装独立に要求を記述し、次に実装(物理レベル)を考える。「概念のバイ
パス」を平気でしたり「概念をそのまま実装できないから」というのは、概念
の意義や重要性が理解できないところから来ているのではないか。
(3)画面・帳票はデータ項目の集まりであり、その仕様はデータ項目の仕様を
規定すれば規定できる。このときデータ項目の標準化/共用を図る。これは客
観的に決まるという意味で設計というより分析である。これを「データで記述
する」ということがある。
(4)「データで記述する」とは、単にデータを羅列するのでなく、データモデ
ルを用いて、管理対象と属性を明らかにして、たとえば
 [社員#]ー(社員名、性別、・・・)
のように記述し、さらにKEYとRKEYの関係や加工データと加工元データの
関係を記述することである。
(5)これはリポジトリのコンテンツとしてDAにより一元管理され、またユー
ザやSEに公開されてレビューや利用に供される。これに反し「プログラム
で記述する」と一括一塊りの管理となり、詳細はブラックボックスとなる。また
手続き的記述は実装独立になりにくい。したがって「データで記述しても、プ
ログラムで記述しても大差ない」ことはなく、データで書けることは品質、コ
ストいずれの点でもすごくうれしいことである。大げさにいえば、プログラム
で記述することが諸悪の根源であり、プログラムは少なければ少ないほど良い。
(6)業務アプリとは、その成果物である画面・帳票に具体的な、社員#、社員名、
受注#、顧客名、品名、受注数量、などのデータ項目が規定されている(セマ
ンティックスを扱う)ものをいう。必ず概念DBが介在するため、処理はI
(DBへ入力)、P(DB内での加工)、O(DBからの出力)に分割できる。
一つの処理の中でIPOを扱うのは、PFAP(プラットフォームアプリ)の
特徴である。
もうひとつの原因は、推測ですが、「業務アプリはそんな簡単なものじゃない。
いろいろな異常処理、例外処理がある。そんなDOA至上主義で片付くはずは
ない」といった過去の経験から来る直感があるように感じました。
私は「概念レベルで、データで記述できないものは、I、P、Oのいずれに含
まれるどんな処理でしょうか、具体的事例を教えてください」とお願いしたの
ですが、不調に終わりました。
■データモデルとPFAPへの分解
13号で述べたように、私は「業務アプリ=データモデル*PFAP」の因数
分解が実現できるとうれしいな、と考えています。概念と実装の分離、ビジネ
スモデルとソフトウエアの分離です。そのため、まずはユーザの情報要求を
100%データモデルで表現したい。これによってユーザの要件をすべてリポ
ジトリに収容できます。私はまえから「データモデルで表現の難しいものとは
何か」を探しています。ありましたら是非教えてください。
PFAPとはセマンティックスを含まない処理ロジックです。WORD、EXCEL、
GUI プログラム、LPのプログラム、CADプログラム、有限要素法プログラム、
レポートライター、汎用エンティティ登録・更新・削除、参照整合性チェックプ
ログラム、などです。ITの進歩によって変わることはありますが、ビジネス
環境の変化によって変わることはありません。
100%データモデルで記述できていれば、効率問題もありますし、例外的に
PFAP化の難しい処理ロジックは従来通り実装して良いでしょう。その分
メンテは余分に発生しますが、効率や作りやすさとのトレードオフとして仕方
がないと考えられます。この例外的ロジックだけの共用/再利用のメリットは
知れていますから、このためだけに難しいオブジェクト指向を取り入れる必要
はなさそうに思われます。
■OOAへの疑問
私の勉強不足もありますが、オブジェクトという用語が人によって違う(ガー
トナーも同意見)ため疑問がなかなか解消しません。業務アプリへのOOAに
ついてはたとえば次のような疑問をもっています。どなたか答えていただける
とうれしいのですが。
(1)OOAでもRDBは使いますよね。DB設計では概念から物理へ変換するは
ず。この概念DBとはどう関わるのでしょうか。OOAには実装独立の話が見
当たらないように見えますが、どうなってるのでしょうか。
(2)OOAは分野統合にどう対処するのでしょうか。ERPの普及とともに、
アプリ統合、企業内統合さらに企業間統合が課題になりつつあります。関与す
るデータ項目は5万から数十万になり、そのセマンティックスを調整しなけれ
ばなりません。このときの数との戦い、スケールアップ問題にどんな対策を用
意しているのでしょうか。
(3)DBを介したコミュニケーションとメッセージによるコミュニケーション
はどう使い分けるのでしょうか。メッセージのセマンティックスはどう調整す
るのでしょうか。概念レベルでは、すべて概念DB経由と考えて良いのでしょ
うか。
(4)オブジェクト切り出しの客観的基準はないのでしょうか。ないとするとレ
ビューが難しく、工業製品というより芸術品になり、品質を上げるには自然
淘汰しかなくなります。PFAPなら数は限定されるので、共用も可能でし
ょうが、(IBMのSan Franciscoのように)アプリのデータ項目がとりこ
まれ、これがビジネスの変化により変わるようなら、とても共用どころではな
くなるのではないでしょうか。
(5)異なったデータモデルに、同じロジックが適用されることはないでしょう。
データ(データ項目、アウトプット、インプット)の標準化・共用を前提にロジ
ックの共用があると考えます。データをまず切り出し、これにこれを作るロジ
ックを対応付ければ、客観的にデータとロジックのペア(オブジェクトのよう
に見える)が作れます。そして次にこのロジックのPFAP化を図る。コミュ
ニケーションはすべて概念DB経由になります(物理的にはメッセージが飛ぶ
でしょうが)。これは一種のOOAなのでしょうか。
(6)DOAでは得られず、OOAで得られるメリットとは何でしょうか。「OO
Aが難しいのは発想の転換が必要だから」という説明をいただきました。その
難しさは何によって報われるのでしょうか。
■なぜOOA
私はOOAを業務アプリに適用するに至った経緯に関して、つぎのような仮説
をたてました。「ユーザの情報要求をデータモデルとして完全には記述できそ
うにない。DBを前提に処理をI、P、Oに分割するのも難しそうだ。だから
セマンティックとロジックはこみこみのIPOになる。そこでOOAによりカ
プセル化して、部品化しよう」。
その原因は、「(1)サブタイプごとの処理を表現できないデータモデル機能の不
備と、(2)概念DBにおける思考の不慣れ、(3)OS開発以来のIPOで処理を考
えるメーカー的パラダイムに引きづられた」ためではないかと。
以上大変フランクに考えていることを述べました。他意はありません。OOA
の疑問を少しでも解消し、「難しいOOAをマスターしなくては」と悩んでい
るユーザ企業のかたがたの不安を少しでも緩和できればと考えてのことでした。
                                椿正明
追伸
このDRI通信は、1996年10月以来毎月1回発信しております。EMAIL
アドレスを頂いた方にとりあえず送信しておりますが、ご不要の方は遠慮なく
ご連絡ください。すぐにストップいたします。またバックナンバーの欲しい方も
お申し出ください。すこし時間をいただくかもしれませんが、送信いたします。