はじめまして、赤坂です。
ひとごとながら、活発な議論で楽しそうですね。
平鍋さんと同じく[00382]をたまたまOnTimeで見て、
投稿したくてウズウズしてました。
# 中心議論も分からず、おそらく枝葉の部分にコメントしては、
# 発散気味の議論を収束不可能な状態にしてしまうのではないかと思って
# 控えていたのですが・・・。
Kenji HIRANABE(Mobile) wrote:
> At 14:24 05/05/12, naka aki wrote:
> >余談っぽいですが、私は、
> >Dataの「Flow」が
> >メッセージのやり取り(や、それを図示したシーケンス図など)で
> >表現できない、という点が不満に感じていたりします。
>
> 私もです。
OMT出身(正確にはP.Codeの「OOA」が最初)の私としては、
なんでUMLにDFDが入らないんだろうと思っていたくらいです。
# 初期のOMTではクラスの操作レベルをDFD(正確にはActionDFD)で
# 記述していたので、エセ構造化上がりの私には合点のいくものでした。
でも今は、ちょっと気持ちが変わってきています。
> 特にシーケンス図とコラボレーション図において、ぼくは引数の
> オブジェクトや返り値のオブジェクトを、Data Tadpole で書くこと
> をよくやります。UMLには規定されていませんが、便利です。
いまだ愛用のRoseで書けるので、私も愛用しています。
ただし、これを使うたびに、私は自問します。
これってホントにオブジェクト指向的なアプローチなのか?と。
# 別に便利だからそれで良いんですが。
平鍋さんの仰るとおり、Value Object とか Transfer Objectなど、
Objectのフローを使うシーンは、実は結構ある訳で、
これらを素直に表現できると嬉しいですよね。
一方考え方を変えれば、こういう使われ方をするオブジェクトは決まっていて
ステレオタイプで識別できれば、わざわざ表記しなくても意訳しながら
モデルを読み進めることも可能だと考えています。
Objectのフローに着目した図が書きたければ、
{UMLに限定するなら}Activity図にした方が良いでしょう。
さらに言うなら、DFDの方が良いかも。
# なぜなら、ダイアグラムごとに得意とする表現内容が異なるからです。
でも、(先のメールで気が付いたのですが)構造化とオブジェクト指向には
根本的に適用範囲に差があると思うのです。
# この詳細については、後で書きたいとは思っていますが・・・。
・・・
で、今回のお題のコンテキストは、対象の領域を理解・整理する最初のモデリン
グですよね。
この業界では概念モデルかユースケースのモデリングですよね。
# このお題に関して言えば、ユースケース図は指定されていないので前者に決ま
りです。
じゃ概念モデルは何を表現するのかといえば、その対象(の業務知識)を理解しな
がら整理します。
ユースケースが対象のサービス(機能など機能やステップ)を整理するものだから、
概念モデルでは対象の知識（用語）やそれらの関係が見えればよい訳です。
ということで、あまりデータの流れについては意識する必要がないと思います。
# もしかしてそういう話ではないかも知れません。その時はゴメンナサイ。
# 対象をよく知っているなら別ですが、これから知ろうとするのなら、最初から
システム化は
# 考えない方が良いですよね。どうせ、ろくなアイデアは浮かびませんからね。
乱文乱筆しかも長文になってしまいすみませんでした。
# 決して荒らしではありません。この議論が発散しないことを望みます。
失礼しました。
--
赤坂 英彦 (akasaka.h@....com)
http://d.hatena.ne.jp/Akapon/