2009年11月 1日 「実践編-11 T字形 ER図の拡充」 を読む >> 目次にもどる

 

 TM (T字形 ER手法の改良版) は、モデル として、以下のように構成されています。

                  (F-真)
  ┌──────────────────────────────────┐
  │                                  │
  │         ┌───────┐                │
  │         │       │                │
  │        ─┘       └─               ↓
  y (形式的構造) ←    f    ← x (語彙) ← 「情報」 ← 現実的事態
           ─┐ (L-真)  ┌─
            │       │
            └───────┘

 すなわち、

 (1) 事業過程・管理過程で使われている 「情報」 を in-put とする。
 (2) 「情報」 に記述されている語彙に対して 「形式的構造」 を与える。
 (3) 「形式的構造」 と現実的事態を対比する。

 (2) を 「tentative modeling」 と云っています──すなわち、「文法」 に従って、語彙を前提にして文を構成する、ということ。構文論重視の作業と云っていいでしょう。そして、(3) を 「semantic proofreading」 と云っています──すなわち、構成された文が現実的事態と対比して、「真」 かどうかを験証する、ということ。意味論重視の作業と云っていいでしょう。

 以上の作業は、以下の 2点を前提にして、「事業を 『正確に』 記述する」 ことを目的としています。

 (1) ユーザ 言語を変形しない。
 (2) できるだけ機械的に構成する。

 さて、「事実を 『正確に』 記述」 したならば、以下の 3点を考慮して 「構造」 を修正します。

 (1) 再設計の目的
 (2) 現 やりかた の強み・弱み
 (3) 現 やりかた の環境適応力

 以上の 3点のなかで、「再設計の目的」 は、ユーザ が すでに提示しています。ただ、ここで われわれ システム・エンジニア が注意しなければならない点は、ユーザ が抱いている実現目的が、現 やりかた と対比して、実現できる範囲にあるかどうか ということを見極めなければならない。実現目的は、ユーザ が望んでいる改善なので、現 やりかた と隔たっているのがふつうですが、その隔たり [ 距離 ] を システム・エンジニア は或る程度 計量しなければならない。たとえば、「コスト を30%削減する」 という目的が示されたときに、TMD のなかで、コスト に係わる データ が どの 「箱」 (entity、対照表、対応表、再帰表など) のなかに記述されていて、どういう 「関係」 のなかで どのように並ぶのか を観て、それらの構成のなかで目的を実現できるのか、それとも、構成の変更──既存の データ を使った新たな構成──を考えなければならないのか、さらに、いままでにない新たな構成を導入しなければならないのか、を考えなければならない。

 と同時に、形式的構造のなかで、ユーザ の気づいていない 「潜在的な問題点」 が存在していないかを システム・エンジニア は感知しなければならない。システム・エンジニア が、もし、そういう 「潜在的な問題点」 を感知したならば、それを ユーザ に伝えて、対応を協議しなければならない。

 上述した問題点を把握するには、現 システム の 「事実を 『正確に』 観る」 しかない。問題点に対して ソリューション が考えられたならば、その ソリューション を 「構造的」 な プログラム として構成することを私は悪いと謂わないけれど、irrelevant だと思っています。私は、寧ろ、「抽象 データ 型 (abstract data type)」 のほうが legitimate だと思っています。というのは、「抽象 データ 型」 のほうが 「事業 (現実的事態)」 と その 「形式的構成」 の対応が わかりやすいので。まず、「事実を 『正確に』 記述」 した形式的構成を基礎資料にして、以下の補助資料を使えばいいでしょう。

 (1) 再設計の目的を具体的な実現数値で 3つほど列挙する。
 (2) 現 システム の長所 を 3つ、短所を 2つ 列挙する。

 再設計の目的は、「戦略的 (stratigic)」 な考慮点──すなわち、環境の変化に対する適応点──を扱い、現 システム の長所・短所は、「問題解決型 (issue-solution)」 の改良点を扱っています。これらの 2点を実現するために TMD を修正 [ 推敲 ] します。ここで くれぐれも注意しなければならない点は、形式的構成を変更したならば、かならず、変更点に対して 「アトリビュート・リスト」 を作成して 「『制約・束縛』 を網羅的に検証する」 という点です。DA (Data Anayst) は、往々にして、TMD (「妥当な構造」) を作ることばかりに興味を示しますが、モデル が モデル として使われるためには、「真とされる値」 が充足されるための 「制約・束縛」 を ひとつとして見逃してはいけないことに もっと注意を払っていただきたい。

 以上の作業が終われば、いよいよ、実装形を作る作業に進みます。実装形の作りかたは、次回 説明します。 □

 



  << もどる HOME すすむ >>
  目次にもどる