@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

UML:関連クラスの誤解について

投稿者投稿内容
みゅう
会議室デビュー日: 2004/12/14
投稿数: 4
投稿日時: 2004-12-14 16:12
UML BASIC LECTURE(3)
関連や関係の落とし穴-4
上記のページに載っている図6のどこが間違っているのか本文の説明だけではわかりません。
「貸出」がクラスになっているのがおかしい、という声もあがったのですが。
どこが間違っているのか?
どうしたら正しくなるのか?
ご教授願います。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-12-14 16:55
私もこの記事の内容には疑問があります。

「これはいい換えると、関連クラスのインスタンスは両端の参加クラスのインスタンスが特定
されれば一意に定まる、ということを意味します。」とありますが、関連クラスにそんな
制約があったでしょうか。貸出に期間を属性として持てば(普通持つと思いますが)「図書」+
「利用者」+「期間」で一意になるので問題ないと思います。
#ファウラー本にも同様の例が載っていますね

引用:

みゅうさんの書き込み (2004-12-14 16:12) より:
「貸出」がクラスになっているのがおかしい、という声もあがったのですが。


貸出は「ストリームラインオブジェクトモデリング(あー長い)」でいうところの「トランザクション」
ですからクラスとして扱うのはまったく問題ないと思います。
kdmsnr
会議室デビュー日: 2002/07/11
投稿数: 3
投稿日時: 2004-12-14 19:08
「貸出」を関連クラスにしてしまうと、ある図書とある利用者の貸出が唯一になってしまうのが問題です。つまり、本文で言えば、

> 同じ利用者が同じ本を時期を違えて借りることは許されているし、実際にあり得るからです。

というところで、貸出という事象があり得るのにこのモデルだと表現できない、という点が問題です。関連クラスではなく、通常のクラスにすることで、ukさんのおっしゃるトランザクションとして処理できます。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-12-14 20:36
すいません、ファウラー本の例は「UMLでは許されない例」でしたね。ですから説明としては
正しいですね。

うーん、でも関連クラスのこういう制約ってわかりにくいですね。「販売」-「明細」-「製品」
の例でも普通のクラスとしてモデリングしたほうがわかりやすいと思います。
みゅう
会議室デビュー日: 2004/12/14
投稿数: 4
投稿日時: 2004-12-14 21:10
ukさん、kdmsnrさん、ありがとうございます。
引用:

kdmsnrさんの書き込み (2004-12-14 19:08) より:
「貸出」を関連クラスにしてしまうと、ある図書とある利用者の貸出が唯一になってしまうのが問題です。つまり、本文で言えば、

> 同じ利用者が同じ本を時期を違えて借りることは許されているし、実際にあり得るからです。

というところで、貸出という事象があり得るのにこのモデルだと表現できない、という点が問題です。



普通のクラスとしていたらトランザクションとして処理できるのはわかるのですが。。
関連クラスですと、ある図書とある利用者が唯一になってしまうということがわからないのですが。。。


[ メッセージ編集済み 編集者: みゅう 編集日時 2004-12-14 21:10 ]
kdmsnr
会議室デビュー日: 2002/07/11
投稿数: 3
投稿日時: 2004-12-14 22:07
引用:

普通のクラスとしていたらトランザクションとして処理できるのはわかるのですが。。
関連クラスですと、ある図書とある利用者が唯一になってしまうということがわからないのですが。。。


えーと、関連クラスというものがそういうものだからです。
関連クラスは通常の関連に制約を与えます。
その制約のひとつがこれです。
みゅう
会議室デビュー日: 2004/12/14
投稿数: 4
投稿日時: 2004-12-20 23:37
ukさん、kdmsnrさん、ありがとうございました。

まだちょっとわからない点がありますが、これから勉強していきたいと
思います。
guion
常連さん
会議室デビュー日: 2004/12/24
投稿数: 30
投稿日時: 2004-12-25 10:31
引用:

kdmsnrさんの書き込み (2004-12-14 22:07) より:
えーと、関連クラスというものがそういうものだからです。



「UMLの」関連クラスは、そのように定義されてる、
ということなのですよね?

…不便ですね、UMLの定義は。

不便というか、無意味な制約だと思います。
だってそうする必然が無い。

関連の線(UML用語でいえばリンクでしょうか)が
オブジェクトじゃなく単なる線であるうちは、
2つのノードの間に複数の線を引くと「識別不能」に陥るので
複数引くことを禁止する必要(論理的必然性)がありますが、
関連の線をオブジェクトにしてしまえば、
複数の線を区別することは容易です。
(↑そのためのオブジェクト指向だ、とも言います(^^;。個体識別重要。)

つまり、複数引けないという制約は、
単なる関連から関連オブジェクトへと継承(?)されるべきではなかった、
と思うんですが、
UMLの中の人は、そう決めてしまったわけですね?

うわ、使えないなあUML。

となると、
UMLの下でモデリングする限りは、複数の関連オブジェクトを
同一ノード間には引けない、
引きたければ「UML以外の道具を使う(藁)」、ってなことになる
のだと思います。
うーん。UML以外の図法(太古には、Booch法とか、色々有ったと聞き及んでます)
を編集できるツールが欲しいですねえ(^^;

#たぶん始めましてm(__)m
#てゆーか先ほど初登校したつもりだったんだけど、出ないなー。失敗したかな?

引用:

関連クラスは通常の関連に制約を与えます。
その制約のひとつがこれです。



えーと。制約という語の(ここ(もしかしてUML?)での)意味を
よく理解してないんですが、
自分が日ごろ馴染んだ意味だとすると、
「通常の関連は関連クラスに制約を与えます」
という言い方のほうがすっきり来るんですが、どうでしょうか?

つまり、

関連<|---関連クラス

みたいな継承関係なのかなーと。

スキルアップ/キャリアアップ(JOB@IT)