--- sadman0@....jp からのメッセージ：
(SadManさんは、文末に「。」をつけない派のかたなのですね。)
>表現する事と思考段階で紙と鉛筆で下書きする事を分けて論じる事に疑問を感じます
まず「紙と鉛筆」が必須といいたいわけではないですので、
その点は私もパスということで。
次に、分かれるといっても単純に2つに切り離したいわけじゃなく、
両者の間に無段階的な中間状態もあると思っています。
1つの数直線(?)の両端に「表現」と「思考」が有り、
その間でうろうろするみたいな感じ。
で、だんだん「表現」のほうに歩いていく感じ、かな。
なお、その過程が、作業を保存してるDocumentの各リビジョンであっても良い、とは思っ
ています。
版が進むにつれて段々「表現」に近づいていくDocumentね。
>ステートチャートではアクションやシグナルが書けますよね
そのアクションやシグナルの「先」に何があるか、が書けないですよね。
シグナルの発信元とか、アクションによって影響が及ぼされる先とかが。
他の図には書いてあるのかも知れないけど、その図には。
ただ、それじゃ図として巨大すぎるものになっちゃわないか？という危険は
あるわけですが…。
＃で、妥協案としてタグジャンプ。
>なにか新しい人が来るたびに図の読み方と表現の意図などを
>毎回説明しなければならない事態にならないでしょうか？
それは規格化とかデファクト化とか、とにかくスタンダード化すれば
解決することです。 UMLのように:-)。
一方、巨大化により読みにくい(描きにくい)絵になっちゃう恐れのほうは、
さすが(?)に私も気になっています。
しかし、UMLだと今度はブツ切り過ぎるように思えるんで…。
>恣意的ではないから共有が可能なのだと思っています
まずすみません。
http://members.jcom.home.ne.jp/w3c/kokugo/kotoba/Shiiteki.html
のような「誤用」を、私もしているようです。
ここでは私はたぶん、
「意図的」などという言葉を使ったほうが良かったかも、と思います。
で、(UML策定者による)意図的なモノとしてのUMLですが、
策定者の嗜好にどんな偏りがあろうとも:-)、
そのせいで必ずしも他人に読めない記法を作ってしまうとは「限らない」ですよね…。
そこそこのものを作ってくれる可能性は常に有ります。
あとそれ以前の問題として、
「UMLじゃ伝わらない」事柄も実際に沢山あるわけですよね。
(そのなかの1つが私が気にしてる問題です。)
そういう意味では、UMLが実現してる「共有」は、あくまで限定的なものです。
>キャッチボールのような物をどう実現するのか分析していく過程に
>局所的表現が現れるように感じるのです
キャッチボールで喩えられてる概念が、
「局所的」な概念とは限らない、ということのような気がします。
別のアプローチをするならば、
それ(キャッチボールみたいな何か)って「パターン」じゃないの？という指摘が
既に有ったかと思いますが、
確かにそういう捉え方で捉えるのも可能そうです。
ただ私としては、あまりにも頻出するパターン
(キャッチボールで私が喩えたいソレは、頻出すると私は思っています)で、
しかもそいつがメタっぽいパターンである場合は、
それを記述する言語(ここではUML)において
出来ればマクロ化したいなぁと思います。
>それは、分析やモデリングという手段ではなく表現=目的物と感じます
んーと、よく判らないんですが、
「それで済むならそれでいいのでは？回り道しなくて済むわけだし。」
と、つい思ってしまいました。
>キャッチボールのような物を直感的に分かるように表現できたとしたら
>それは既に実装ではないでしょうか？
オブジェクトのやりとり自体は、あくまでメタな道具(つまり手段)に過ぎないと思います
。
それこそキャッチボール自体をキャッチボールでメタファしようなどという
(あほな)ことをやらない限り。
オブジェクトのやりとりは、ほんとに至るところで出てくると思います。
>漠然とした森を実装していくために限られた(共有できる既知の)視点に分解し
分解というか投影(モデルを或る方角から見る)のベクトルとして
10本目のベクトルが欲しいなぁ、と思っています。
>ですから、大局的なものを厳格に表現したいという要求が起きないのです
私が言ってる奴を、私は格別に「厳格」だとは思っていません。
もちろん何かを厳格に表現するための手段として「も」使えるとは思いますが、
モノのヤリトリという概念は、
もっと素朴で大雑把に思考している段階においても出てくる(頻出する)もの
だろうと私は思うので。
(「オブジェクト指向」ってそういうもんだろ？と思っています。
確かにMessageSendingはOOならではの特徴ですが、
MessageSending「だけ」で物事が成り立っているわけじゃなく、
既存技術(概念)であるところの「(そのMessageの結果として)状態が変わる」
というところを組み合わせて考えて、初めて1つの技術的実体になるんだと思います。)
クラス図とかは分析でも設計でも実装でもそれぞれ使う、ってのと
似てると思っています。
私が言ってるソレ(を図示する何らかの図法)も、
粒度や上中下流の区別にかかわらず使えるのではないかと。
(上手さんお勧め(ですよね)の「モデリングセルフレビューノート」に
シーケンス図は分析工程でも使う、ってなことが書いてあったので、
ちょっと胸を撫で下ろしてるところです。
シーケンス図は中流下流でしか使わないんだ！なんて言われちゃったら
(説得が)大変なことになりそうなんで…。)
ーーーー
ところで妥協方法。
うーん、アクティビティ図(オブジェクトフローも描けるのでしたね)の
「レーン」をMessageをやりとりする個々のオブジェクトだと
強引に見なせば、一応私が描きたいものを描けるのかな。
でも、フローで流されてるほうのオブジェクトも、
途中で動的にレーンの立場に鞍替えしたくなることも(そして逆も)ある
ような気もするんで、やっぱりイマイチかな。
__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/