中村です。ありがとうございます。
(児玉さん曰く)
>関連クラスっていうと,関連線に破線で引き出したクラスですよね。
そうです。JUDEでも最近実装されたアレです。
#「私にとって待望の」機能がやっと付きました。
>あれは,リンクに属性を持たせるだけなので,{Set}の制約を引き継いでいます。
>{Bag}を明示するか,
「属性」ですか。
UMLにおける「属性」という言葉の意味を知らない(すみません)ので
正確なところは判りませんが、なんとなくベースならば判るような気がします。
「制約を引き継ぐ」という点については、
以前この私の悩みを友人に相談したところ、
「関連から関連クラスを導出(?)するときに
その制約自体を(UML作った人らが)Overrideしてくれれば
良かったのにね」
と言っていました(^^;
つまりその制約がついてる場所がHotSpot(改造の急所)になっててくれりゃ
済んだ話なのじゃないかと。StrategyPatternみたいな感じ。
以上、私や彼がUMLの作者じゃないからには詮無きことではありますが、参考までに…
>Chenの言う“Relationship”
> A 1---* C *---1 B
>
> ↑
> relationship
うーん。実装というか「概念レベルより一段下のレベル」としては
そういうデコードをするのもアリでしょうけど、
概念レベルでは、そういう妥協(^^;は、したくないところですね。
幸い、{Bu^Hag}制約をかませば回避できるとのことなので、
今後は(何をするに際しても)そっちのほうで考えていこうかなと思います。
ところで、
「A 1---* C *---1 B」
という書き方の気に入らない点は、
1:
それが「こと」(つまり関連)であるということが、
絵柄的にピンと来るような仕掛けを、伴っていない。
(そのてん関連クラスなら見た目のケバさもバッチリなのですが…)
ヤボったいし、
上記のように上流工程(^^;でやるべき事ではないと思う。
2:
多重度の書きかたに一種のトリックが必要となる。
関連として捉えたときの多重度を、
relationshipとして捉えたときの多重度に、
「変換」してあげないとならない。
(たしか左右入れ替えたりするんでしたよね。)
それが大変気持ち悪いし面倒。
といったところです。
個人的には、「使い物にならんな」と思っています。
>もの(A)−こと(C)−もの(B)の「こと」です。私は広義の関連
>クラスと言っています。
「Cが「こと」を表す何かである」という意味付けは、
relationshipを使おうが、UMLの関連(関連クラス)を使おうが、
かわらないものではないのでしょうか?
つまり、
「もの(A)−こと(doC関連クラス)−もの(B)」
と書いてしまっても
構わないというか、同じ事だというか…
> 「関連オブジェクト」とおっしゃっているのが「広義の関連クラス
> のオブジェクト」ならば,そのとおりです。
私が「期待」しているものはソレではないので、
残念なことではあります。
まあ幸いにして(教えてくださって有難うございます){Bag}で乗り切れそうです。
#そういや制約周りも今回バージョンのJUDEの機能強化点でしたね。
それにしても、この{Bag}制約の有無によって、
オブジェクト図を描くときの重複の許可/不許可を
実際に制御してくれちゃうような、
気の利いたUMLツールってのは、
今のところ現存しない…のかな…
__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/