こんにちは、赤坂です。
# やっぱり、返信もらえると嬉しいですね(^o^)
naka aki wrote:
>>これってホントにオブジェクト指向的なアプローチなのか?と。
>
>
> UMLのやり方が(唯一の)正解、というわけじゃないでしょうから、
> いいんじゃないか？と思っています。
そうですね。僕もそう思います。オブジェクト指向が唯一の考え方ではないし、
UMLで表現できなければ、別のポンチ絵でも良いですよね。誤解なく伝われば。
> 現状のUMLだと、なまじ図ごとの着目点が絞られてしまってるだけに、
> (しかも着目点自体が押し着せの9通りに限定されてしまってるんで)
> 「盲人の象撫で」に陥りやすいんじゃないかと…。
うーん、そうなんでしょうかね?
# 鼻を触った盲人は像は長い、とか全体が見えないって話ですよね?
まあ、お仕着せなのはその通りなのですが、
それはオブジェクト指向という考え方に（一応）合致するもの
だとは思いますので。
UMLで表現しようとすれば、ある程度考え方も強制されるのも
仕方ないかなぁと思います。
そんな理由から、UMLで表現しにくいケースってのは、
もしかしてオブジェクト指向の考え方から外れたのかな?って思う訳です。
# もちろん、オブジェクト指向に「従う」つもりはさらさらありません(^^;;
・・・あ、そっか。UMLしか見えない盲人って事ですね。
確かに確かに。
> オブジェクトのやりとりについては、
> MessageSending(狭義の)だけに注目して考えてしまうと、
> なんというか、あたかもオブジェクトがみんな「止まって」いるかのように
> 捉えてしまったことになっちゃうんじゃないかと、心配しています。
そうですね。
私の理解では(多分間違ってると思いますけど)、
対象の世界に住むオブジェクトさん達は動かないですね。
ただし、自身の状態によって振る舞いを変えるものもいます(⇒クラスの状態図)。
# でも、ほんとにこれで良いの? > 自問。
> あえて言えばオブジェクト天動説というか。オブジェクト様は動かないのだ！
というか。
> で、それって果たしてオブジェクトの「動き」を分析／設計したことになるの
かな？
> と疑問に思っています。
オブジェクトが(+自身の意思で)動くのは、私の理解ではエージェント指向です。
もちろん、そういう考え方を否定していませんよ、念のため。
# ちなみに、私はエージェント指向に惹かれて、この業界に入った人間です。
UMLで表現しにくいのは、それはオブジェクト指向の枠を超えているからなんだと
勝手に思っていますが、書ける様になるなら歓迎します。
# ただ現状で動くものが作れなくなってしまうのなら、残念ながら使えないです。
> そうでなく、むしろ動き(移動)のことを考えてこそのオブジェクト指向
> なんじゃないか？とすら思っています。
(オブジェクト指向かどうかはおいておいて)それもアリ！ですね。
私もそういうものを分析・設計してみたいです。楽しそうですもんね(笑)。
でも、私の理解では図面と言うより、映画のスケッチというか漫画みたいに
シミュレーションできるものをモデルとして作らないとダメなような・・・。
CASEツールがそれをサポートしてくれたら嬉しいですけどね。
あとはある程度いろんな環境で、実装もテストも可能であって欲しいです。
# 映画もできるくらいだから、やってやれないことはないのでしょうが。
UMLを拡張、あるいは別の表記法でもいいですが、オブジェクトの動きを
2次元の紙面にスナップショット的に表現することは可能なんでしょうか?
私は、現状の少なくともUMLにおいては、オブジェクトを固定することによって、
それらの相互作用をお仕着せの図面で表現できることを保証している気がします。
あと、ちょっと話がそれますが(すみません、私の興味範囲ということで・・・)、
ダイナミックに型が変わるようなオブジェクトって、UMLではどう表現するので
しょうか?
あとは型のないクラスとか・・・。
# このあたりは、すでに実現可能な言語の機能として存在していますよね?
>>Objectのフローに着目した図が書きたければ、
>>{UMLに限定するなら}Activity図にした方が良いでしょう。
>
>
> というよりも、
> Message(つーかSelector)Sendingと、Objectのやりとりとの
> 「絡み」
> に着目したいんです。
ごめんなさい。
私はメッセージはオブジェクトだと思っていましたが、勘違いでしょうか?
# 逆にオブジェクトはメッセージとは限りませんが。
UMLではきっと、期待する「絡み」は表現できないでしょうね?
上記の例では動くObjectは、Messageのパラメータに過ぎないのでは?
オブジェクトが動くということなのか、オブジェクトの位置を知らせる行為なのか
どっちなんでしょうね?
> それを素直に描ける図がUMLには無い…。
オブジェクトを動かないものとして、そいつから見える動きを表現するくらいしか
UMLでは一貫性を保証できない、というか、そもそも表現できない気がします・・・。
それでも個人的には、DFDを使いたいシーンはいまだに存在しています。
特に、オブジェクト指向で考える前の状況整理においては必須だったりします(^^;;
>>構造化とオブジェクト指向には
>
>
> 元来、「動き」と「構造化」には
> なんの相関関係もないんですよね。
>
> たまたま計算機の歴史として
> 振る舞いのみ(^^;を構造化して捉えるという伝統が一部(?)にあった、
> というだけのことで。
>
> (たとえばデータだって構造化できるわけで。)
先のオブジェクトの動きと私の好きなDFDとは確かに関係ないですが、
パラメータとしてオブジェクトがやり取りされて、
変換(操作呼び出し)されるということなら、DFDでも表現できるのかな?
と思ったのでしたが、ちょっと違うようですね。
> また、「動き」が必ずしも構造化で捉えるのに似合うものとも
> 限らないですし。
そうですね。データの変換プロセスですからね。
> 玉突き衝突とかブラウン運動とかって、構造化で捉えると
> おかしなことになるんじゃないかなあ？
> (詳細に考察したことはありませんが、勘で。)
私も構造化はかじった程度なので、確かなことは分かりませんが、
nakaさんと同感です。
構造化では、玉突き衝突やブラウン運動をどうするのか(例えばシミュレーショ
ンする)
決まれば、それに必要なデータ変換プロセスを決めていくのでしょうね。
もしかして勘違いかも知れませんが、この辺が、
対象をわりと素直に整理できそうなオブジェクト指向(あるいはUML)との
違いなのではないかなと思っています。
あと、抽象度を事由に設定できるかどうかということも決定的ですね。
DFDでは各ダイアグラムをブレークダウンする際に上位レベルの図と
入力と出力を整合させないと意味がありません。
一方、オブジェクト指向は詳細化するときに、抽象レベルを落としながら
具象レベルに構成することが自由にできます。
# もちろん、そのせいでトレーサビリティが取りにくくもなる訳ですね。
また、発散気味になってしまいまして、申し訳ありません。
ではでは。
--
赤坂 英彦 (akasaka.h@....com)
http://d.hatena.ne.jp/Akapon/