Index: [Article Count Order] [Thread]

Date:  Thu, 28 Apr 2005 17:10:52 +0900
From:  Hanyuda Eiiti <hanyuda@....com>
Subject:  [modeling-dojo:00357] 汎化とインスタンス関係の使い分け再論
To:  modeling-dojo@....jp
Message-Id:  <20050428170421.4BF7.HANYUDA@....com>
In-Reply-To:  <200504220709.AA05376@....jp>
References:  <20050422020654.5527.HANYUDA@....com> <200504220709.AA05376@....jp>
X-Mail-Count: 00357

児玉さん

こんにちは,羽生田です.
どたばたしていて間が空いてしまい失礼しました.

このまま質疑を続けていてもなかなか収束しなさそうなので,
(柔道でいえば,脇の甘いところがない自然体で,技が効かない:-)
まず最初に言いたかったことだけを端的に書いてしまいますね.
その上で,なにかコメントをいただければと思います.

そもそも児玉さんの出されたモデルは何度も改訂を重ねて
非常に完成度の高いものになっておりあまり突っ込みようがないのですが,
1点だけ私として気になったのは,「サービス」というクラスのクラス名です.

(1)他のクラス(この場合は特にお預かり品)との関係を見れば間接的に
あぁ,このクラスは,1回1回のサービスではなく,サービス型を表わしているク
ラスなのだな,というのがわかります.(最初のメールでは,わざとボケをかま
して,お預かり品---サービスの関連のサービス側の多重度が変ですよ,と突っ
込んで勘違いしやすいクラス名であることを示唆してみたのですが.)
ですから,やはりモデル読者のことを考えて,「サービス型」クラスないしは
「サービス種」クラスという名前にすべきではないかと考えた次第です.
長いメールのやり取りになってしまいましたが,今回言いたかったことは,この
1点のみです.

(2)2回目のメールでは,この主張を補強するために,「サービス」クラスのサブ
クラスである「加工」クラスや「クリーニング」クラスのノートとしてこれらの
インスタンスはそれぞれ「防水加工,防虫加工」,「ドライクリーニング,水洗
いクリーニング」と書かれている点を問題にしました.ノートもモデルの構成要
素と考えれば,やはり,本来,防水加工や防虫加工は加工クラスのサブクラスと
考えるべきであり(言葉遣いの問題ですけどね),防水加工や防虫加工をインス
タンスと位置づけるのであれば,今のモデルで「加工」クラスとしているものは
「加工型」クラス,同様に「クリーニング」は「クリーニング型」クラスに変更
すべきで,その結果,それらのスーパータイプの「サービス」クラスは「サービ
ス型」クラスとした方が誤解が生じづらくわかりやすいですよね,と言いたかっ
ただけです.

最初のメールを出したときの意図は,以上の指摘を通じて,パワータイプという
わかりづらい概念の説明も明らかになればよいな,と思っていたのでした.
自然言語で「サービス」といった場合に,それば実体として何を指しているのか
は結構微妙ですが,児玉さんは明らかにサービス種という意味で「サービス」ク
ラスを使われているので,意味的にこのモデルはまったく間違っていません.
というわけで,非常に簡単な,児玉さんにとってはたぶん当たり前のことで,単
なる言葉遣いの違いだけなので,問題にされていなかったのだろうと思います.

===ここまでが端的に言いたかったこと===

ここからはおまけです.(以上の主張がなかなか伝わらなかったおかげで
いろいろ議論のネタが出ました)

実は,わたしが提出した第0版モデルでも同じ問題を抱えているのですが
それを伏せて児玉さんのモデルで議論させてもらったのでした(胸を貸していた
だきありがとうございました).たぶん,この後,ブラッシュアップして第1版モ
デルにする段階で,サービス種というクラス名に改訂すると思います.

次に,パワータイプについてです.
(3)わたしはまず頭の中で
・a1:このYシャツにドライクリーニングを実施する.
・a2:このYシャツにクリーニングを実施する.
・a3:このYシャツにサービスを実施する.
とすべて自然に言えるから,ドライクリーニング,クリーニング,サービスの3
概念は同じメタレベルにあると認定しました.ですから,仮にサブタイピングで
それをとりあえず表現すれば,
サービス<|---クリーニング<|---ドライクリーニング
サービス<|---クリーニング<|---水洗いクリーニング
となるだろうと考えを進めます(以前のメールでは,この仮想的な話の部分を
サブクラス化してはおかしいと突っ込まれてしまったのでした).
そして,次の段階で,ドライクリーニングと水洗いクリーニングの振舞いの区別
に興味がないという判断がなされた時点で,ではこれらの概念をクラスとして表
現するのは過剰モデル化となりますので,なんらかのタイプのインスタンスとし
て扱う必要があると判明します.このタイミングで,クリーニングに対するパワー
タイプを考えることになります.それが「クリーニング型」であり,そのインス
タンスが,ドライクリーニングや水洗いクリーニングということになります.こ
の段階で,「クリーニング型」は元の「クリーニング」クラスよりもメタ階層が
1段階上がったことになります.

(4)以上のことを踏まえて,児玉さんのモデル中の「サービス」クラスは実はパ
ワータイプに相当するのですよね,と最初のメールで質問したのでした.モデリ
ング作業の結果として提示されている児玉さんのモデル中には,「サービス」ク
ラスをパワータイプと考えた場合のベースクラスは含まれていません.ですから,
厳密な意味では,児玉さんのいうように「サービス」クラスはパワータイプでは
ない,といえるかとは思います.が,そのモデルに至る(3)で述べたようなプロ
セスを想定すれば,個々のサービス実体を表わすクリーニングや加工をベースク
ラスにとるパワータイプとしてクリーニング型や加工型が導入され,そのスーパー
タイプとしてサービス型(これは児玉さんのモデルでは「サービス」クラス)を
パワータイプと位置づけるのはごく自然なことなのではないかと考えたのです.

このことと関連して,児玉さんの以下の文章にコメントさせてください.

On Fri, 22 Apr 2005 16:09:28 +0900
Kiminobu Kodama <kiminobu-kodama@....jp> wrote:
>    >別の例で示すと,
>    >「自動車」クラスと「乗用車」クラスや「運搬車」クラスとの関係に汎化関係を
>    >使っておきながら,
>    >一方で,「乗用車」のインスタンスとして「スポーツカー:乗用車」,「運搬車」
>    >のインスタンスとして「トラック:運搬車」とモデル化するようなものではない
>    >でしょうか.これらは自然な概念分類の考え方からすると,やはり,スポーツカー
>    >は乗用車のサブクラス,トラックは運搬車のサブクラスとすべきでは.
> 
>  意味が分かりません。スポーツカーを乗用車のインスタンスとするか,
> 乗用車のサブタイプとして,さらにその下に何らかのインスタンスを考
> えるか,あるいは,ずーっとサブタイプを考えるかは,自然な概念分類
> という評価基準では判断できませんよね。むしろ危険だと思います。
> 
>  どこで分類を止めるかは要求(とモデルの視点)に照らして決めるべ
> きと思います。

(5)サブクラス化をどこまで進めるか打ち止めにするかの判断は児玉さんのおっ
しゃるように要求や制約をミニマルに表現できるモデル構造という観点で判断す
べきなのはいうまでもありません.ですから,児玉さんがなぜ防水加工や防虫加
工を独立したクラスにしなかったかの説明は非常に見事だと思います.

(6)ただ一方で,インスタンスとタイプの区別はできるだけ人間の常識的な概念
化階層にもとづいて定式化しておくべきではないでしょうか.

名称 メタレベル    例
M3  概念の概念の概念 とりあえずなし
M2  概念の概念    自動車種,乗用車種,クリーニング種,サービス種
M1  概念       自動車,乗用車,スポーツカー,預かり品,クリーニ
ング,サービス
M0  実体,現象    品川あ1234:自動車,MYシャツ101:預かり品,ドラ
イ0428007:クリーニング

業務ドメインによっては,その対象がどのメタレベルに属するのか曖昧な存在も
あるかもしれません(その場合も,M0レベルとして何を想定するか意識あわせを
すべきでしょう.また,M0は考えられなくてある種の概念から出発しなければな
らないドメインもあるでしょう.その場合も,相対的なメタレベルは論じられる
はずです).しかし,一般には,
自動車種と自動車とスポーツカーと品川あ1234:等のメタレベル(相対的なレベ
ルの区別)が要求や制約によって変動すると考えるべきではないと思います.
自動車種とスポーツカーの間がタイプ-インスタンス関係なのであって,自動車
とスポーツカーの間はあくまでスーパータイプ-サブタイプと考えたいです.こ
うした常識的な概念階層(オントロジー)を前提にするのがオブジェクト指向モデ
リングだと考えているのですが.極限までウオッカムの剃刀を働かせるべきで人
間の認知的常識などは無視しても制約を満たすミニマルなモデルを追及すべきと
いう立場はあり得るとは思いますが,わたしは採用しません.(6end)


とりあえず以上です.

よろしくお願いします.

Hanyuda Eiiti,  hanyuda@....com
Chairperson, Object Software Engineering Consultant, Mentor
MAMEZOU CO., LTD   http://www.mamezou.com/
163-0434 Nisi-Sinzyuku 2-1-1 Sinzyuku-Mitui building 34F, Sinzyuku-ku, Tokyo JAPAN
TEL +81-03-5367-5830   FAX +81-03-5367-5831