Index: [Article Count Order] [Thread]

Date:  Sun, 20 Mar 2005 01:38:22 +0900
From:  Makoto Minagawa <kitsune@....com>
Subject:  [modeling-dojo:00243] Re: こんなん出ましたけどぉ>UML記述を理解できるお勧め本ありま
To:  modeling-dojo@....jp
Message-Id:  <20050319224637.D396.KITSUNE@....com>
In-Reply-To:  <BE618F5C.120E8%eiichi@....com>
References:  <20050319013416.9F83.KITSUNE@....com> <BE618F5C.120E8%eiichi@....com>
X-Mail-Count: 00243

 ども、皆川%相変わらずレスポンスが遅くてすいません@豆蔵です。

 林さんはいつも素早いですねー。

# 以下、例によってメールの引用部分を一部削らせていただいています。

On Sat, 19 Mar 2005 08:12:12 +0900
Eiichi Hayashi <eiichi@....com> wrote:

> 会長である世帯主から町内会への2つの関連線からみた多重度
> が両方1になっていることがポイントですね。
> そうなっていると世帯主が会長の役割を持たないことがあり
> えなくなってしまうという解釈でいいんでしょうか

 はい、そのとおりです。「会長」ロールの反対側の多重度が何気なく「1」に
なってしまっているところが今回の問題の落とし穴でした。この多重度との兼ね
合いで、元のクラス図…

+--------+  1          1..* +--------+
| 町内会 |◇----------------| 世帯主 |
+--------+             会員 +--------+
    | 1                        1 | 会長
    +----------------------------+

…に合致する可能なオブジェクト図のパターンは、以下の[A],[B]および[B']の
形のいずれかに限られてしまうことになります。

======================================================
[A]
                  会員
+-----------+ -------- +-----------+
| c1:町内会 |     会長 | S1:世帯主 |
+-----------+ -------- +-----------+

======================================================
[B]
                  会員
+-----------+ -------- +-----------+
| c1:町内会 |     会長 | S1:世帯主 |
+-----------+    +---- +-----------+
      |          |
      +----------------------+
                 |           | 会長
+-----------+ ---+     +-----------+
| c2:町内会 |     会員 | S2:世帯主 |
+-----------+ -------- +-----------+

======================================================
[B'] ([B]のパターンの繰り返し環構造)

+-----------+     会員 +-----------+ 会長
| c1:町内会 | -------- | S1:世帯主 | --------+
+-----------+          +-----------+         |
      |                                      |
      +----------------------+               |
                             | 会長          |
+-----------+     会員 +-----------+         |
| c2:町内会 | -------- | S2:世帯主 |         |
+-----------+          +-----------+         |
      |                                      |
      +----------------------+               |
                             | 会長          |
+-----------+     会員 +-----------+         |
| c3:町内会 | -------- | S3:世帯主 |         |
+-----------+          +-----------+         |
      |                                      |
      +--------------------------------------+

======================================================

 上記、いずれのパターンでも、ある「町内会」オブジェクトに二人目の「世帯
主」オブジェクトを「会員」として関係付けようとすると途端に閉じない無限連
鎖が始まってしまい、オブジェクト群の関係構造を構成することができなくなり
ます。

# 児玉さんが書かれていた制約を加えると、上記[A]の形だけしか明確に存在で
# きなくなりますね。

> 世帯主が会長にならなくてもいい図はこうですね。
> 
>  +--------+  1          1..* +--------+
>  | 町内会 |◇----------------| 世帯主 |
>  +--------+             会員 +--------+
>     | 0..1                     1 | 会長
>     +----------------------------+

 はい。そのとおりですね。

> しかし、これだけだと児玉さんの制約がないと、会員でない町内会の
> 会長になれてしまうことになると思います。

 これも仰るとおりで、「自分が会員になっている町内会でないと会長にはなれ
ない」というルールがある世界では、児玉さんの書かれた以下の制約…

> >  context 町内会
> >  inv: self.会員->includes(self.会長)

…が、かかっていないと厳密さを欠いてしまいます。ただし、「他の町内会の会
長になることもできる」という世界では、その限りではありません。

 というわけで、元のクラス図を考え直して私たちの常識により合致している(
もうちょっとしっかりした)クラス図に描き直してみたとすると(たとえば)次の
ようなモノになるでしょう。

+--------+  1                  1..* +--------+
| 町内会 |◇------------------------| 世帯主 |
+--------+      ↑             会員 +--------+
    | 0..1      |{subset}            1 | 会長
    +-----------------------------------+

# 上図の関連間に引かれている線は依存関係の線(オープン・アロー・ヘッドが
# 付いた破線)だと思って見てください。

 図中の{subset}というのはUMLで特別に用意されている関連間の制約で、児玉
さんが書かれた制約文とほぼ同等な意味を持ちます。真面目にモデリングしてい
るとこのような制約を付加しなくてはならないケースが結構出てくるので、UML
ではあらかじめ簡易な記法が提供されているということですね。

 今回のパズル問題は、とてもシンプルなクラス図で(無意識のうちにクラス名
から連想される私たちの「常識」も働いて)一見良さげに思えてしまうのですが、
実際には頭の中で考えているものとは違う変な構造を表現してしまっていた…と
いう例です。ここから得られる教訓は、『よく考えず安易に多重度(特に「1」の
ようなとても制限の強い多重度)を付けたりすると、ぜんぜん違った構造を{表現
して|伝えて}しまったり、その影響が思わぬところに出てきたりして、ちょっと
痛い目に会ったりすることがありますよ』…といった感じでしょうか。

> ところで、多重度未指定にして誘導可能性を片一方にする
> っていうのは、反則でしょうか
> ただ、この意味は会長になった世帯主自身は、自分はどの
> 町内会の会長か知らないことになりますね。(笑)
> 
> 
>  +--------+  1          1..* +--------+
>  | 町内会 |◇----------------| 世帯主 |
>  +--------+             会員 +--------+
>     |                            ↑
>     |                          1 | 会長
>     +----------------------------+

 誘導可能性(ナビガビリティ)と多重度は関連に対するそれぞれ異なった側面の
特性を示すモノなので、基本的に無関係だと(私は)考えています。つまり、(基
本的に)誘導可能性を片方向にしたからと言って、片側(反対側)の多重度を未指
定で放っておいても良いということにはならないと思っています。

 誘導可能性とは「その関連で参照する時、相手のオブジェクト群が{直接|低コ
ストで}特定できるようにしておいてね」という指定のことで、これが片方向で
あっても「逆方向のオブジェクト群を特定することはできない」とまでは限定し
ていないと(私は)解釈しています。たとえば、上のクラス図の例だと、ある「世
帯主」オブジェクトが会長を務めている「町内会」オブジェクトは、すべての
「町内会」インスタンスの中から該当する「世帯主」オブジェクトを「会長」と
して参照しているモノを探し出せば(参照コストはとても高いですが)特定するこ
とができるでしょう。

 片方向関連の反対側の多重度は「そのオブジェクトが同時にいくつの相手から
参照されている可能性があるか」という情報を示しています。この情報は(たと
えば)「排他制御が必要か?」等の設計上の想定を行う場合の重要なヒントにな
るので、明示されているに越したことはありません。

# 実装段階に入った時、設計モデル中にこれが明示されていない箇所が残ってい
# る(決めきれなかった)場合は、ワースト・ケースとして「0..*」を仮定して備
# えることが多いです。

 以上、このメールが何かのお役に立ちましたら幸いです。

--
  /|/|  ▲      皆川 誠 @ 株式会社 豆蔵
 /    ノ /  }      「きつねはコンと鳴く」
 |// ノ /   |   会社用: kitsune@....com
 =o=|\|   /    自宅用: kitsune-san@....com
   く  |  /     携帯用: kitsunex@....jp
    ■■■■