» 【第7号】モデル

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

DRI通信 7号 「モデル」              1997.4.1
 
先回は
  ビジネスモデル(概念)ーDOA
  ソフトウエア (物理)ーPOA
の対比で述べましたが、案外反応がありませんでした。あたりまえなのか、逆に
「みんなが言ってないとんでもないこと」なのか、どちらなのでしょう。
■割り切りによるモデル化
さて今回はモデルについて考察する。モデルとは「型」、「定型」のことである。
具体的な事例に含まれる共通の性質を抽出して作られる。すべての性質に囚われ
ているとモデルはできない。抽象化するのである。選択・割り切りが重要である。
「人間は動物である」、「人間は動物ではない」、「人間は考える葦である」、
「人間は土のちりと神の命の息から造られた」。どのような性質を抽出するかに
よっていろいろなモデルができる。モデルによって予測ができる。型にはめて整
理ができる。単純なモデルほど強力である。


■洞察と当てはめを繰り返す
モデルをつくるきっかけは「似ている」ところに気がつくことではないか。これ
は感覚の問題であろう。共通点と相違点が混在している。共通点を分離し、構造
ないしアーキテクチャーを推定する。ここには洞察・インスピレーションが必要
である。
構造とは、「要素」と「要素間の関係」から成る。どんな種類の要素から成って
いると考えればよいのか、その要素間にどんな関係を定義すべきか。関係がなけ
れば要素は独立である。問題は別々に考えればよいからやさしくなる。関係とは
からみであり制約である。関係は極力単純なものがよいと言えよう。要素の種類
が適切でないと関係が必要以上に複雑化する。
はじめは簡単な事例をもとにモデルをつくることになる。洞察も荒削りなもの
であるから、複雑な事例にあてはめるとうまくゆかない。モデルの修正、当ては
めを何回も繰り返すのである。理論と実験をベースにする物理学の方法と同じで
ある。科学の普遍的な方法なのであろう。
■ビジネスモデルは概念/論理レベルで
THデータモデルの場合は、IO、データ項目、定義域、概念ファイル(エンテ
ィティ)、データベースタイプなどを基本的な要素として選び、その関係を検討
していった。その際、概念/論理レベルにこだわった。ユーザの問題はビジネス
モデル上で発生し、解決もビジネスモデル上に返されなければならないからである。
加工データと加工元データの関係をモデル化すると、処理ロジックが解明される。
マクロな処理の流れ、すなわち「だれが、いつどのような条件のとき、どんな目
的で、どんなIOを生成するか」を示す業務モデルも、まずは概念/論理レベル
で考えるべきである。データが概念/論理レベルで把握できるならばその処理/
変換過程も概念/論理レベルで把握できるはずである。
ビジネスモデルにおいて、データモデルと業務モデルは、車の両輪のようなもの
である。前者におけるサブタイプ問題、後者におけるC/Sやオブジェクト指向
との関係は大きな課題であったが、リポジトリの構造が固まり、ほぼ解決のめど
がついたように思われた。そこで、これら両モデルを、3月26日ソフトウエア
THeRepository (TH extennded repository) とともにPLAN−DBユーザに公
開した。DOAの推進とモデルのリファインを期待しつつ。
ビジネス世界には、人、組織、IO、データ項目など、厳然として動かせない管
理対象が存在する。したがって客観的なモデル化のアプローチが可能である。し
かしソフトウエアそのものはオーバーに言えばいかようにもつくれ、客観的なモ
デル化が難しい。ソフトウエア工学がはかばかしい成果を挙げられなかった理由
は、ビジネス世界の分析をバイパスして、直接ソフトウエアのモデル化に取り組
んだためではないだろうか。
オブジェクト指向が、実世界をモデル化の対象にしようとしているのは、この反
省から来ているようにみえるが、ここで概念/論理を重視しないのはなぜであろ
うか。
■基本ソフトへのDOA
さきのDRI通信4号において、「業務アプリケーションはデータ中心で、(通
常は)基本ソフトはプロセス中心で」と述べた。しかし基本ソフトも、より本質
的なモデル化のためにはデータ中心アプローチが必要になるに違いない。
この場合は、まづコンピュータの世界の構造/アーキテクチャーをどのような要
素の種類から成ると考えるかが基本となろう。そこでユーザ、クライアント、各
種サーバー、ネットワーク、ディスク、またそのシリンダー、トラック、ページ
、データセット、通信されるファイル、パッケット、OSのジョブ、タスク、メ
ッセージ、レジスター、メモリ、バッファ、ロードモジュール、スクリーンなど
種々のの管理対象を識別し、その属性やこれらを管理するテーブルそのものなど
を対象に、徹底したデータモデリングを行う必要があろう。
アーキテクチャを決めるということは、それを構成する要素と要素間の関係を決
めることであり、これを分析すればエンティティと属性は自然に決まるもののよ
うに思われる。これによって機能間の適切なインターフェースも決まってくる。
したがって、このモデル化の議論が進んでいれば、CORBAがよいかDCOM
がよいかなどの議論も、もっと科学的に進められるはずと思われるがいかがであ
ろうか。このような分析抜きにいきなり解決策─言語仕様やソフトウエアインタ
ーフェース標準化─の話しがでてくるために、力を背景にした政治決着が横行す
るのではないか。
強力な図面言語とサブタイプや処理ロジックを明快に扱うTHデータモデルは、
ここ─コンピュータの世界のモデル化─でも威力を発揮することができるのでは、
と私は期待しているのだが。
                              椿 正明