今日は、上手です。
議論についていけていませんが、一部だけコメントします。
> モデル(というんだろうか？)の妥当性を検証しやすくなる、
> のではないかと期待してます。
>
> いや、これもまた「モデル」といえるのかな…？
> よくわかんないです。
>
> ＃そういう意味では、このMLの範囲から逸脱してないかどうかは自分にもよく判りません
> ＞上手さん
> ＃どこまでをもって「モデリング」と呼べるのでしょう？
この辺りは、実は自分でも整理しようとしているところです。
【視点１】
システム開発のモデルでは、分析、設計、実装の時間軸でモデルの内容は変わっ
てきます。開発方法論でもつくるモデルは違ってきます。構造化設計、DOA、OO。
UMLはオブジェクト指向のモデリングの（一応の）公式標準に過ぎないですね。
UMLの中でも、どの図を使うか。
オブジェクト図については、システムのある時点でのスナップショットで、クラ
ス図に含まれても良いと定義してあった記憶があります。＃（uml仕様書）
【視点２】
児玉さんの「UMLモデリングの本質」のP237に、モデリングとは何かという章が
あって、エイコフ氏、ブライアン氏のモデル定義などが紹介されています。
エイコフ氏
アイコン型も出る
類比型モデル
分析型モデル
ウィルソン氏
概念型モデルを追加
・観察者が対象をどう認識しているかのイメージ
＃この内容には、もっと深い学問的な裏付けがあると思いますが、児玉さんにお
願いします。
【視点３】
EA（エンタプライズアーキテクチャ）はビジネスモデリング、ドメインモデリン
グそのものですね。
そうすると、ビジョン、ゴール。戦略、目標、アクションといったビジネス行動
の導出とか、ビジネス戦略の妥当性の検証という視点と必ずつながります。
これはもう、経営コンサルタントの世界ですが、モデルの構造としては無視はで
きません。
＃この辺りの記述性の強化については、非常に興味があります。エリクソン／ペ
ンカーとか、マーシャルとか。
【視点４】
個人的には、モデルは、単なるマッピング（写像）と思っています。
表現するべき対象を、表現したい内容の軸で切り出しているものと思っています。
ですから、UMLも、DOAも、DFDも、EAも、最も有効な手法・道具を使ってモデル
を描けばいいと思っています。
問題なのは、「自分がモデリング対象領域のマトリックスの中のどの部分をどう
いう制約でモデル化しようとしているか」をきちんと認識することだと思ってい
ます。
そして一番恐れることは、渡辺幸三さんもBLOGで述べられているようなこと。
「まずUMLありきで、その中の細かいルールの解釈に関心を奪われてしまうこと」
だと思っています。
＃私が実装は全く駄目、ということがそう考えさせているのは事実です。
＃上の引用ソースを探していて、渡辺さんのBLOGをさまよっていておもしろかっ
たページです。（肝心の引用部分がみつからなかった・・）
◆モデリング技術の破壊力
http://watanabek.cocolog-nifty.com/blog/2005/04/post.html
◆「スクラッチ開発」という名のゴムボート
http://watanabek.cocolog-nifty.com/blog/2005/05/post_5643.html
◆構造化分析設計手法の問題
http://watanabek.cocolog-nifty.com/blog/2005/05/asistobe_df5c.html
（では）