今年 （2009年） 最初の 「ＴＭの会」 でした。「ＴＭの会」 は 5年目を迎えました。役員もいないし、運営専任者もいない自主運営の会が 5年を迎えたというのは、ひとえに、会員の皆さんが モデル の学習に直向きだからでしょうね。「ＴＭの会」 が長く続くことを期待しています。
さて、今回から、「モデ 家」 の TMD に関して、アトリビュート・リスト の作成を本格的に はじめました。前回、アトリビュート・リスト の作りかたを説明したので、今回は、アトリビュート・リスト を実際に作って、アトリビュート・リスト を作るときに、どのような点を配慮すればいいかを実演しました。
● 事業の 「実態」 は、アトリビュート・リスト に現れる。
「モデル」 は、以下の 2点を実現しなければならない。
（1） 「妥当な」 構造 （L-真）
（2） 「真とされる」 値 （F-真）
「妥当な構造」 を作る手段が TMD で、「真とされる値」 を検証する手段が アトリビュート・リスト であり、「妥当な構造」 を作る際に前提になっている技術は 「論理法則」 ですが、「真とされる値」 を検証する際に確認すべき点は、取引上の制約・束縛 （約束事） であることを、前回、説明しました。
「妥当な構造」 は、論理法則を知っていれば──文法違反さえしなければ──作ることができるので、「妥当な構造」 を作ることは、それほど難しい仕事ではないでしょうね。すなわち、論理法則を覚えて、実践の場数を 多数 踏んで 「慣れ」 ればいいというだけのことです──「文法」 上 （構文論上） の テーマ にすぎない。
いっぽう、アトリビュート・リスト の作成は、「真とされる値」 が どのようにして決まるかという 「（事業上の） 制約・束縛」 を記述するので、モデル 作成では、非常に難しい仕事です。数学上 「モデル の『解釈』」 と云われているのは、この 「付値」 のことを云います。ただ、（それぞれの項を 「真 （F-真）」 とするための） 「制約・束縛」 を 「理解する」には、「事業過程の渦中にいる」ということが絶対前提です。「受注」という意味を理解するためには、「受注」のしかたを説明されたあとで、「受注」の行為を実際にやってみて、そして、事業過程のなかで期待されているとおりに行為（反応・適用）できたならば、「受注」を理解していることになるでしょう。しかし、われわれ システム・エンジニア は、事業過程・管理過程の手続きを実地に経験できる訳ではないし、そんなことを期待されている訳でもないでしょう。
そうだとすれば、われわれが やらなければならないことは──あるいは、「事業過程を 『正確に』 記述する」 ことを期待されている われわれが 唯一できることは──、「制約・束縛」 として考えられる可能態の すべて を列挙して、それらの可能態のなかで どれが実際の 「制約・束縛」 として導入されているのかを エンドユーザ に確認することしかないでしょうね。そして、この 「制約・束縛」 の網羅性を確認することが アトリビュート・リスト の役割です。ちなみに、ときには、エンドユーザ さえ、「制約・束縛」 の いくつかを見落としています。
「制約・束縛」 を確認するときに、以下の諸点を配慮してください。
（1） ∀x ということを確認すること （「充足」 されているか。∃x という事態はないか。）
（2） 「全順序」 では、以下の関係を検証すること。
（2）-1 ＜ （小さい）
（2）-2 ＝ （等しい）
（2）-3 ＞ （大きい）
（3） 「半順序」 では、以下の関係を検証すること。
（3）-1 ≠ （べつべつの外延）
（3）-2 ⊇ （包摂する）
（3）-3 ∩ （いちぶまじわる）
（3）-4 ⊆ （包摂される）
（3）-5 ＝ （同じ）
→ 板書写真 （1）
以下、実演した レビュー のなかで、代表的な アトリビュート のみを記載しておきます。
● 「契約日」 の アトリビュート・リスト
（1） 「商品」 （resource） の アトリビュートとの 「制約・束縛」
resource （商品） は、「商品区分 コード」 で ブロック 化 （類別） されて 「契約」 に
関与しているので──言い換えれば、「契約」 は、resource （商品） に対応するよう
に サブセット 化されているので──、まず、「書籍 （商品の サブセット）」 の アトリ
ビュート と対比しました。そして、「書籍」 の アトリビュート とのあいだには、「制約・
束縛」 はないことが明らかにされました。
（2） 「取引先」 （resource） の アトリビュートとの 「制約・束縛」
「契約」 HDR の 「再帰」 構成は、「取引先」 が 「代理店」 のとき、そして、そのときに
限り起こる （if and only if）。
（3） 「契約」 のなかの アトリビュート との 「制約・束縛」
「データ 計上日」 とのあいだで 「全順序」 関係があるかどうか を確認しました。
「データ 計上日」 は、検討の末、除去していいことが明らかになりました。
なお、TMD 上、「稲廼家 （いなのや）」 という語は、「去る」 という意味です （笑）。
私の家の近所に 「稲廼家」 という 「そば屋」 があって、私は、20数年間、その 「稲廼
家」 を 「いねのや」 と読んでいたのですが、最近になって、「いなのや」 という読みで
あることが明らかになりました。「いねのや」 の 「いね」 を古語の 「去 （い） ぬ」 の
活用形 （自ナ変） に こじつけて 「その場を立ち去る、いた場所からいなくなる」 という
意味で使っています──洒落 です。「モデ 家」 とは、なんら関係がない。
（4） 「契約明細」 との 「制約・束縛」
「契約」 DTL が起こるのは、「（「商品」 が） 多言語」 のとき、そして、そのときに
限る （if and only if）。
なお、アトリビュート・リスト を作成しているときに、それぞれの アトリビュート に関する 「制約・束縛」 を検証すると同時に、「事業の やりかた」 も聴きだしています──たとえば、上述の例で云えば、「（取引先の） 再帰」 （代理店の存在） とか 「多言語」 とか [ これらの諸点は、TMD を レビュー しているときにも確認していますが、さらに、アトリビュート・リスト を作成するときにも、再確認しています ]。というのは、集合 （entity） のあいだで構成を作っているときには、集合間の関係しか重視していないので、アトリビュート のあいだの 「制約・束縛」 が集合間の関係を変形することがあるので。
→ 板書写真 （2）
● 「契約期間」 の アトリビュート・リスト
（1） デフォルト 値 （5年）。
（2） 「契約期限日」 との 「制約・束縛」
5年を超えたら、「自動更新」する。
（3） 「自動更新 フラグ」 との 「制約・束縛」
（3）-1 「自動更新」 かつ 「自動更新 フラグ ＝ 1」 のとき、「同一契約番号」 で更新する。
（3）-2 「自動更新」 かつ 「自動更新 フラグ ≠ 1」 のとき、「新しい契約番号」 で更新する。
なお、「契約期限日」 「自動更新フラグ」 の アトリビュート・リスト は割愛します。
「契約期間」 は、「契約期限日」 の計算式で使われます。「契約期限日」 は導出項目です。
→ 板書写真 （3）