＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-04 12:55
関係ないと思っているんなら、最初から function という概念が OO にとって有害とか言わないでください。 | ||||||||||||||||
|
投稿日時: 2005-02-04 13:30
"「集合」なくして「写像」はありえず、「写像」の主体は「集合」である。" こちらに関しては私の中で概念が固まっていないので何ともいえませんが、 "「情報」なくして「振舞」はありえず、「振舞」の主体は「情報」である。" こちらには異論があります。 私もこのスレッドと以前のスレッドを追いかけていますが、 私の考え方としては本田さんが示された"タイプA.「振舞」のみ"にあたります。 あまり良い例ではないかもしれませんが、人の髪の色というものについて考えてみてください。 一般生活の中では、「あの人の髪は黒色」「彼の髪は茶色」など、 C#であれば「あの人.髪.色==黒」「彼.髪.色==茶」といった、このスレッドで言うところのプロパティで表され、 一般生活の認識過程とさほど変わらない形で、ドメイン空間モデルからソフトウェア空間モデルへ実装できます。 しかし、"一般生活の中では、「あの人の髪は黒色」「彼の髪は茶色」"これ自体が（ドメインモデル作成手順として） 正しい認識なのでしょうか? と言いますのも、「彼の髪は茶色」という「情報」を得る為には、 「彼の髪を見る（調べる,伝聞を聞く）」などといった「振舞」が前提としてあるはずです。 「彼の髪を見た結果、黒色」といった形です。 また、「彼の髪の色」自体も、その人の先天的性質（DNA、母体環境）や 後天的事象（年齢、染色）によって設定されているはずです。 （DNA,母体環境,年齢なども何らかの外部要因によって設定される。 染色はそのまま「振舞」として認識できる。 述べるまでもありませんが「設定」はsetter、つまり「振舞」です。） 本田さんの書き方を踏襲しますと、私の考えは、 "「振舞」なくして「情報」はありえない。「情報」は「振舞」の結果の産物に過ぎない。" ->（飛躍すると）"「情報」は無くとも、「振舞」で全てを記述できる。" #要不要の問題（"「振舞」は無くとも、「情報」で全てを記述できる。"が立証され得るのか）ではない、 #という事を添えさせていただきます。 という認識です。 #C#のPropertyは、getかsetの「振舞」でありますが、その実態を隠し、「情報」に見せかけているに過ぎない、 #というふうに私は考えています。 #その為、上記説明文中で"このスレッドで言うところのプロパティ"という回りくどい言い方をしました。 | ||||||||||||||||
|
投稿日時: 2005-02-04 13:41
定義の問題ではないですか？ アナリシスパターンに期待したいところなのでは？ この手の話をし始めると、 目で見えたものだけがオブジェクトだったりプロパティ足りえるし、 目に見えないものはどうでもいい・・・になりません？ 目で見えたものがそれだと思ったとしても、 事実誤認であった・・・であれば問題になるのではないでしょうか？ 枠を広げるのはかまいませんが、 掘り下げもしないで枠を広げようってのは 概念の階層を崩すのでは？ 既存のUMLに加筆をするのが前提であれば 既存のUMLを知らなければ問題外ではないですか？ 既存のUMLの欠点としての指摘が （メリット・デメリット含む） 問題視されているかどうかです。 現状である程度表現できるものを問題視するのであれば、 欠点を列挙してしまうべきではないでしょうか？ 抽象論でおかしい・・・と言う場合、 個人の感性に合わない・・・と言う場合もあります。 −現実 ドメイン ソフトウェア− 現実＝ソフトウェアを目指すのであれば、 UMLを −ドメイン ソフトウェア− に一度限定してしまって −現実 ドメイン− に新しい言語を模索するのなら話はわかります。 その上でつなぐつなぎ手段を考えればよいと思います。 全てを一度に議論している状態なのではないかと考えています。 | ||||||||||||||||
|
投稿日時: 2005-02-04 14:11
えー？？私は 「OOAの中でfunction指向の考え方はありえない。」 といっているのであって、 リアルドメイン-OOA->モデリングドメイン-OOD->プログラムドメイン というモデリング手法を考えたときに、 「OODの中ではデザインパターンなどで functionという修飾子はありえるけど、OOAの中ではオブジェクトを 定義する上でfunctionという修飾子は有り得ない。」 と言っているんです。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-04 14:12 ] | ||||||||||||||||
|
投稿日時: 2005-02-04 14:14
既存のUMLについては議題の中心ではありません。 コミュニケーションのツールとして便利なので使用することはありますが、あくまでもツールです。 コミュニケーションの効率を高めるために必要に応じてカスタマイズする場合もありますが、 それはこのスレッド上での話であって、それを既存のUMLに対して改善案として提案するか どうかは、別問題でしょう。 議論順序としては、 １．リアル⇒ドメイン ２．ドメイン⇒ソフトウェア です。逆にすると手戻りが発生する恐れがあります。 そして、今は１に議論が絞られ始めてる、と思います。 また、１の議論を進める上では、既存のUMLで問題ないと思います。 ただ、 http://www.amazon.co.jp/exec/obidos/ASIN/4795296308/ UMLモデリングのエッセンス―標準オブジェクトモデリング言語の適用 P46-48、第４章「クラス図」の最初にある「観点」の項。 こちらにある「概念的観点」「仕様の観点」「実装の観点」のうち、 「概念的観点」での話しになると思います。（「概念的観点」は言語に一切依存しません） | ||||||||||||||||
|
投稿日時: 2005-02-04 15:27
objectです。
>k-nakさん >本田＠スミテムさん 先ず、時系列を無視してでも、「優先的にレスを付けた方が良い」様なのでここで「レス」します。 >・「写像」は「集合」間の制約条件である。 >・「アルゴリズム」は「データ」間の制約条件である。 >・「振る舞い」は「情報」間の制約条件である。 制約条件という言葉に少しだけ疑問は残りますが、 代数系「集合、写像」の少し詳しい説明として以下を見て下さい。 「符号理論講義資料2」 http://www.ma.is.saga-u.ac.jp/uehara/coding03/codlec02.pdf ----------------------- 2 代数系 2.2 演算と代数系 S を空でない集合とする． どの元 a, b∈S にも，a＊b を表される S の元がただ１つ対応しているとき，つまり， (a, b) → a＊b∈S のとき，この対応づけを S の演算とよび ＊ をその演算記号という． さらに，S が ＊ による演算をもつということを (S, ＊) という記号で表し，これを代数系とよぶ． ----------------------- つまり、「写像」は「集合」の上で考えられている事が重要です。 >「情報」なくして「振舞」はありえず、「振舞」の主体は「情報」である。 >「集合」なくして「写像」はありえず、「写像」の主体は「集合」である。 私も、 「集合」が無ければ「写像」が存在しないから、「集合、写像」には意味がない と思います。 しかし、 「集合」があっても「写像」が無ければ、「集合、写像」には結局意味がない と思います。 そういう意味では、 「集合」、「写像」は対等であり、それらの価値を比較出来るものでは無い という事になるのではないでしょうか？ それから、「プロパティ」は認めないけれど、「フィールド」は使用するというのは、そもそもその「スタンス」に問題があるのではないでしょうか？ [ メッセージ編集済み 編集者: object 編集日時 2005-02-04 15:54 ] | ||||||||||||||||
|
投稿日時: 2005-02-04 15:28
本田＠スミテムです。
について、頂きましたご指摘に答えたいと思います。
これについては、「彼の髪を見る（調べる,伝聞を聞く）」のは誰なのか、考えていただければよろしいかと存じます。 答えの一例は「私」です。 すなわち、「見る（調べる,伝聞を聞く）」は「私」の「振舞」であって、「彼」の「振舞」ではないと思われます。
setterについては、とてもいいところを指摘されたと思います。 実は、私も今のところ、ソフトウェア空間におけるsetterやproperty setは「振舞」ではないかと考えています。 #私の消化不良の一つです。 私の今のところの考えでは、 1.ソフトウェア空間における「情報」の写像は、property getのみです。 2.property setは、「振舞」の写像であるmethodのSyntax Sugarです。 ただし、 3.リアル空間では、そもそもproperty setは存在しません。 です。 例えば、リアル空間で 本田.職業 = 銀行員 という代入はイメージできません。 本田.転職する(銀行員) だと思っています。 そして、こう考える根拠は、「情報」と「振舞」の区別の仕方です。 私は、「情報」と「振舞」はオブジェクトのインターフェース要素であると考えています。 そして、インターフェース要素はメッセージ(刺激)に対する応答です。 メッセージの前後でドメイン空間を比較したとき、変化が無いものは「情報」です。 #object様は「情報」という言葉を使いますが、私はk-nak様と同じく、「状態(State)」と表現したいところです。 「状態」とは「ドメイン空間(の状態)」を「メッセージ」で微分すると0になるものです。 または、 ドメイン空間を写真で撮ったときに見えているものです。 一方、メッセージの前後でドメイン空間を比較したとき、変化があるものは「振舞」です。 「振舞」とは「ドメイン空間(の状態)」を「メッセージ」で微分すると0にならないものです。 または、 ドメイン空間をビデオで撮ったときにだけ見えてくるものです。 以上を踏まえて、
「状態」-(振舞1)->「状態'」-(振舞2)->「状態''」・・・ は 「集合」-(写像1)->「集合'」-(写像2)->「集合''」・・・ であり、 "「振舞」は無くとも、「情報」で全てを記述できる。"とは、もともと言っておりませんが、"「情報」なくして「振舞」はありえず、「振舞」の主体は「情報」である。"ということになります。 #うまく伝われば幸いです。 | ||||||||||||||||
|
投稿日時: 2005-02-04 15:49
大いに同意します。 私は「集合」さえあれば「写像」はいらないと言ったつもりはないのですが、未記入様のように誤解されてしまって、少し言葉足らずだったかなと反省しております。 #もし、「集合」さえあれば「写像」はいらないのなら、 #私はオブジェクト指向C(情報のみ)の人間ということに・・・。 #神棚に飾っておくような動かない世界に住まわされるのは勘弁してくださいといった感じです。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.