--- sadman0@....jp からのメッセージ：
>コラボレーションはどうでしょう？
それについては、ビリヤードはあまり良い喩えではないのでナンなんですが
(ビリヤードだとオブジェクト間の関連の変化があまり面白くない。
接触が一瞬しか起きないですからね。
野球みたいに「球を持っている」という状態があったり、
ダーツみたいに「矢が刺さってる」という状態があったりすると、
もうちょっとピンとき易い喩えになったかも。反省。)、
いずれにせよ「引数(などによるObjectのやり取り)」が表現できないという点において
シーケンス図と同罪(^^;ですよね。
関連の変化といえば、
すごく卑近(実装より)なレベルで見れば(例えばJavaでは)Setterメソッド、
ということになりますが、
「そのメソッド(MessageSending)がSetterである」
という点は本質的にはどうでもよくて、
問題とすべき点は
「そのメソッドが呼ばれたら、そのオブジェクトの状態(関連)が変化する」
という点なのだろうと思います。
で、状態が変化すると、それが玉突き追突的に
次の(自分およびそれ以外の)オブジェクトの状態変化を引き起こす…。
つまり
Message→Message→Message…
じゃなくて、
Message→状態変化→Message→状態変化→Message…
なのだろうと思います。
で、UMLだとMessageSendingと状態変化は別の図に描く羽目になりますから、
コラボレーション図→状態遷移図→(さっきとは別の)コラボレーション図→(さっきとは別
の)状態遷移図→(またまた別の)コラボレーション図…
みたいな、すごくせわしい視線の移動が必要になっちゃう。
>(必要なら)全てコラボなりシーケンスで表せると思ったから
コラボレーション図(やシーケンス図)だけを使うなら、
1枚の絵で(MessageSendingの)連鎖をがんがん書いていけるんで、
視線の移動は酷いことにはならないんですが、
それだとMessageの合間にオブジェクトとか[*]の状態がどう変化したか？は
読み取れないですよね。
[*]
そういやUML2ではステート「マシン」図っていうんでしたね。
1つの状態遷移系は「1つの」オブジェクトに宿るとは限らず、
オブジェクト複合体に宿ってると捉えないと不味いことがしばしばであるはず。
もしこれがステート「オブジェクト」図なんていう名称になっていたら、
ぶん殴ってたところです(^^;;
>トリガーを与えてやれば、後は各オブジェクトが勝手に「動く」という物です
それはそのとおりなんですが、それだけだと(つまり現状のUMLだと)、
1つのオブジェクトごとにバラバラにしか見れないんですよね。
まあ、ソースコードを読み書きするツールでいうところの「タグジャンプ」みたいに
言語(ここではUMLの仕様じゃなく、ツールのサポートの仕方によって
視点の移動のいやらしさをカバーするという手も、ないわけではないんですが…
逆にいえば、タグジャンプのような機能がついてないUMLツールは、価値ゼロじゃないか？
という気がしてます。
不満を述べるのはさておき、
とりあえず蔓延ってしまったUML(^^;と現実的に付き合うには、
そういう落し所もありかとは一応思っています。理想的ではないですが。
__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/