Index: [Article Count Order] [Thread]

Date:  Thu, 12 May 2005 14:24:12 +0900 (JST)
From:  naka aki <naka_aki_naka_aki@....jp>
Subject:  [modeling-dojo:00382] Re: 32 番リベンジモデル公開
To:  modeling-dojo@....jp
Message-Id:  <20050512052412.62380.qmail@....jp>
In-Reply-To:  <B4C55619E20C9Emitsuji@....jp>
X-Mail-Count: 00382

--- MITSUJI Takamasa <mitsuji@....jp> からのメッセージ:

>DFDで入れ子構造を用いて段階的に詳細化していく部分は、
>もっと後の工程でオブジェクト間のメッセージのやり取りに
>置き換えられるから

それ、置き換えられてない、と思います。

余談っぽいですが、私は、
Dataの「Flow」が
メッセージのやり取り(や、それを図示したシーケンス図など)で
表現できない、という点が不満に感じていたりします。

オブジェクト間のメッセージのやり取り(OOP用語でいうMessageSending)
を(少なくともUMLみたいなやり方で[*])考えると、
(主に)引数というかたちでやり取りされているオブジェクトが
どうなってるのかが、読み取れない図にしかならないんですよねー。

[*]
これはMessageなる言葉の定義にもよります。
うろ覚えですがたしかSmalltalkあたりでは(間違えてたら御免ね:以下同文)、
メッセージとは
メソッド名とか引数名とかの組み合わせ
(たしかセレクタと呼ぶんでしたよね:畑によってはシグネチャとも言うのかな?)
と、
そのセレクタに対して実際に呼び出しを行う際の「引数値(つまり引数として渡すオブジェ
クト)」
と、の組み合わせ
として捉えるのでしたよね。
(言語実装メタモデル的にいえば、メッセージは、セレクタやシグネチャのインスタンスだ
、とも言えるかなー)

一方、UMLのシーケンス図だとMessageとかは単なる矢印です
(引数も一応書けるけどオプションだし、絵じゃなく言葉としてしか書けないし)。
これってSmalltalkでいうところのメッセージでなくセレクタでしかないわけで…。

で、UMLだと上記の意味でのメッセージが上手く描けない…。

#そういや、この「オブジェクトのやり取り」を描けないと
#動くモノが作れない(だろう)から、 MDAもヘッタクレもない
#のではないかと心配してるんですが、どうなんでしょ?>MDA

個人的には、UMLのシーケンス図みたいなものを少し拡張して、
メッセージ矢印がやり取りしてるオブジェクトもまた図として表せる
ようにして欲しいと思っています。
シーケンス図の一番上(?)にはオブジェクトが並んでいるわけですが、
それらのうちのドレがどの矢印で(引数として)使われてるのか、を図示したい。

素朴な案としては、単に、上のオブジェクトから各矢印へ、点線でも引っ張れれば
いいんじゃないかと思っています。

で、DFDのほうはよく知らないんですがm(__)m、
DataFlowDiagramってゆーからにはきっと、
引数かどうかはさておき、とにかくデータ(OOPでいうオブジェクト)を
どこからどこへやり取りするか?は、ばっちり描かれてるのですよね??
うう、羨ましいですぅ。

UMLでもアクティビティ図ではObjectFlowが描けるそうですが、
アクティビティ図だと今度は粒度が大きいというか、
シーケンス図が似合う粒度の話をしてるとき
(Object個々とかに高倍率で注目してるとき)には使えないというか…。

ーーー
この集まり(道場)の場で言ってもしょーがない話かも知れませんが、
モデリングコンテスト(のレギュレーション)がそもそもUMLベースだという点は、
考えようによっては、足かせなんですよね。

表したいものがUMLで上手く描けるとは限らないのだから。

オブジェクト指向…や恐らくDOAとかでも同じなんでしょうけど…って結局は、
モノ(オブジェクト)間の「関連」が動的に色々と繋がったり切れたり、を繰り返す動きを
取り扱うわけですよね。
#そして、それをメタ化して、ルール(可能性)ベースで捉えたらどうなるかな?って考え
るのが、いわゆるモデリング。
##あ。そうでない面もありますが、ここでは割愛(^^;

なので、それを素直にサポートする図が無い図言語を
モデリングに使うのって、なんか不安になるんですよね…。

UMLのシーケンス図は、私の目から見れば、
俳優の台詞のやり取り(MessageSending?)は書かれてるけど
俳優の姿勢や表情など(状態遷移?)が書かれてない台本、
のように思えることがあります。

味噌は、このObjectSending(仮称)が
OOPそのものでは普通にサポートされてるはずなのに、
UMLではそれを明示的に表すための手段を欠いている、という点
だと思います。
上で「それ、置き換えられてない、と思います」と書いたのは、それです。

おかげで、大抵UMLベースでしか議論されない昨今のモデリング議論において、
このObjectSending(仮称)がすっぱりと抜け落ちがちになる…ような気がする…

#先人が「UMLは表記法に過ぎない」と散々言ってくれたおかげで、
#言語と方法論の独立は(現状の実態としても)守られましたが、
#言語と「考え方」との独立は、ぜんぜん守られてないなぁという印象です。
#しょせん言語は思考を既定するようです。


__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/