「中沢家」 の TMD (TM Diagram) を、前回から ひき続いて、推敲しました。
前回、「社内版」 に関して、以下を考えて、3つ以上の代替案を考える宿題を出しました。
(1) 「個体」 --たとえば、「図面」-- の性質として考える。
(2) 「関係」 のなかで--すなわち、バージョン 管理として--考える。
(2)-1. 社内版を主として、客先版を従として考える。
(2)-2. 社内版を従として、客先版を主として考える。
今回、宿題に対して、4つの案が提示されました。それらの案を検討しました (それぞれの TMD は、ここでは、省略します)。
4つの案のなかで、3つは、「客先版」 と 「社内版」 を 図面に対する サブセット --すなわち、「図面」 の性質--としていました。
TM の文法は、数学の 「解析」 を前提にして作られています。「解析」 とは、数学的な論法の一つであって、証明しなければならない対象 A が存在しているとき、A が成り立つためには、B1 が成り立たなければならないことを示し、さらに、B1 が成り立つためには、B2 が成り立たなければならないことを示すというふうに、以下のように、順次、対象を導出する手順です。
A → B1 → B2 → ... → Bn.
そして、A を、終いには、「既知の ことがら」 Bn に帰着する やりかた を 「解析」 と云います。この 「既知の ことがら」 (管理対象としての個体) が、TM では、「entity」 です--つまり、「事実的な F-真」 を示す (現実の事実を指示する) 物であったり、多くの人たちが 「合意している」 管理対象です。
TMD の作成は、「解析」 の逆を辿ります。すなわち、「既知の ことがら (entity)」 を起点にして、「構造」 を、順次、組んでいきます。したがって、「なんらかの 『構造』 を作るためには、その前に、どのような モノ (entity とか対照表とか) が存在していなければならないか」 を つねに考えるようにして下さい。
「客先版」 は、「取引先の図面」 に対して付与される番号です。そして、「図面」 が 「取引先用の」 図面であるか、それとも、「自作用の」 の図面であるかを判断するためには、「取引先」 が、まず、認知されていて、「取引先」 が提示した図面であることが判断されなければならない。「取引先」 が提示したのかどうかという判断するためには、なんらかの 「手続き (あるいは、事態)」 が先立っていなければならない。その 「手続き (あるいは、事態)」 が 「受注」 である--ちなみに、「受注」 は、TMD には記述されていなかった。
┌───────────────────┐
│ 受 注 E│
├─────────┬─────────┤
│受注番号 │受注日 │
│取引先コード(R)│ │
│ │ │
└─────────┴─────────┘
しかも、「客先版」 には、かならず、「社内版」 が対応 (「1-対-1」 対応 ?) します。
図番 001
┌────┬────┬────┬────┐
│ │ 事態 -1│ 事態- 2│ 事態 -3│
├────┼────┼────┼────┤
│ 客先版 │ 001 │ 002 │ 002 │
├────┼────┼────┼────┤
│ 社内版 │ 001 │ 002 │ 003 │
└────┴────┴────┴────┘
事態-3 が起こるかどうかは、ユーザ に確認して下さい。
「客先版」 と 「社内版」 は、排他的ではないので--同一の個体に対して、かならず、2つが組になって対応するので--、ひとつの認知番号に対して、客先版と社内版の サブセット にはならない。前回、「客先版」 を 「取引先. 図面. 対照表」 のなかの性質としていましたが、「社内版」 との対応を考慮して、「図面」 の VE としました。
4つの案のなかで 1つの案は、「客先版」 を resource としていましたが、resource として認知する (管理する) 積極的な理由はない。というのは、「客先版」 は、単独の個体指示子 (認知番号) として作用しない--同一個体の状態が推移するので、状態の推移を時系列のなかで並べる コードです。
以上の諸点を鑑みて、とりあえず、以下の 「構造」 として整えました。
┌───────────────────┐ ┌───────────────────┐
│ 受 注 E│ │ 製造手配 E│
├─────────┬─────────┤ ├─────────┬─────────┤
│受注番号 │受注日 │ │製番 │製造手配日 │
│取引先コード(R)│ │ │ │ │
│ │ │ │ │ │
└─────────┴─────────┘ └─────────┴─────────┘
∨
| ┌─────────────┐
┼ │ 図面. 客先版 VE│
┌──────┴──────┐ ┌─────────────┐ ├──────┬──────┤
│ 取引先 R│ │ 図 面 R├┼───○<│図番(R) │客先版 │
├──────┬──────┤ ├──────┬──────│ | | |
│取引先コード│取引先名称 │ │図番 │品名 │ └──────┴──────┘
│ │ ├┼─○─<| │ │
│ │ │ │ │ │ │ ┌─────────────┐
│ │ │ │ │ │ │ │ 図面. 社内版 VE│
│ │ │ │ │ │ ├┼────<├──────┬──────┤
└──────┴──────┘ │ └──────┴──────┘ │図番(R) │社内版 │
│ | |更新日 |
│ └──────┴──────┘
┌─────────┴─────────┐
│ 取引先. 図面. 対照表 │
├─────────┬─────────┤
│取引先コード(R)│ │
│図番(R) │ │
│ │ │
└─────────┴─────────┘
さて、この状態では、「図面 (の アトリビュート)」 は、最新の状態しか記録されないでしょうね。「図面 (の アトリビュート)」 の更新された状態も、すべて、記録するのならば、{図番+社内版} が ひとつの個体指示子として作用するので、以下の 「構造」 となるでしょう。
┌───────────────────┐ ┌───────────────────┐
│ 受 注 E│ │ 製造手配 E│
├─────────┬─────────┤ ├─────────┬─────────┤
│受注番号 │受注日 │ │製番 │製造手配日 │
│取引先コード(R)│ │ │ │ │
│ │ │ │ │ │
└─────────┴─────────┘ └─────────┴─────────┘
∨
|
┼
┌──────┴──────┐ ┌─────────────┐
│ 取引先 R│ │ 図 面 R│
├──────┬──────┤ ├──────┬──────┤ ┌─────────────┐
│取引先コード│取引先名称 │ │図番 │品名 │ │ 図面. 更新日 VE│
│ │ ├┼─○─<|社内版 │ ├┼────┼┼──────┬──────┤
│ │ │ │ │ │ │ │図番(R) │更新日 │
│ │ │ │ │ │ │ |社内版(R)| |
│ │ │ │ │ │ │ └──────┴──────┘
└──────┴──────┘ │ └──────┴──────┘
│
│
┌─────────┴─────────┐
│ 取引先. 図面. 対照表 │
├─────────┬─────────┤
│取引先コード(R)│客先版 │
│図番(R) │ │
│社内版(R) │ │
└─────────┴─────────┘
「取引先. 図面. 対照表」 のなかに、「社内版」 が関与するので、「客先版」 を対照表のなかに もどしました。
さて、この時点で、以下の 2点を検討しなければならないでしょうね。
(1) 「客先版」 には、「更新日 (通知日)」 を記録するのか。
(2) 「受注」 は、かならず、「手配」 に先行するのか。
(1) は、「社内版」 には、「更新日 (作成日をふくむ)」 が記録されているが、「客先版」 には、「日付」 を記録するのかという点が検討されなければならない。もし、「通知日」 が記録されるのであれば、上述した 「構造」 は修正しなければならない--「通知日」 が記録されるかどうかは、「中沢家」 が次回までに確認することにしました。
(2) に関して、「受注」 は、基本的に、「手配」 に先立つが、「手配」 が 「受注」 の先立つこともあるとのこと。(2) の構造を宿題としました。
以上の検討の道筋は、tm-net に アップロード されている講義録を参照して下さい。