上手さんへ
レスありがとうございます
>Item は Price に依存する。
>Service は Price に依存する。
>
>依存の向きは確かに逆のようです。
依存は点線だったような？
通常の矢印は誘導可能性の方向で
それが片側にある場合は単方向誘導
よって、
アイテムよりプライスを誘導
サービスよりプライスを誘導
(厳密には両方ないと特定できないのですが
表現方法がよくわからなかった、強いて言えば関連クラス？）
価格から、サービスやアイテムを辿れませんよという思惑でした
依存を引いているのは、チケット、タグのバウンダリぐらいなので
チケットはオーダーに依存する
タグはサービスに依存する
でなんで逆なんだろうと思ってました
>Item は Order の一部です。
>Order は 0 以上の Item を必要とする
>
(中略)
>とすれば良いのですが、上のItemクラスはこの２つのクラスの属性や操作が
>混ざっているようです。このため、背広（種類）をクリーニングに出すと、もう
>同じ背広（種類）はOrderできなくなります。
IDによって同じ種類の品目を区別できなくなるだけで
集約は可能だと思っていましたが、ダメでしたか
その辺をオブジェクト図で表現すべきだったかもしれません
命名が拙かったかもしれませんね
>集約もおかしそうです。
>多重度もおかしいかな。
>Service は Item の一部です。
>Item は 0 以上の Service を必要とする
あぁ、確かに集約を使う必要ってないのかもしれません
単なる情報を辿るリンクですから
アイテムには複数のサービスが「くっつき」ます
ぐらいの感覚で書いてましたが
こういう場合、集約を使うべきではないのでしょうか？
パーシステントとして結び付きが強い情報は
つい集約で書いてしまいます
>２ 日本語に直して関係を読み上げる。
先のポストを見てガイドラインとしてとても良さそうな本だと思いました
SadMan