＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-08 17:36
結構広い範囲で再定義してらっしゃるようですが、
部分的にレスさせてください。
この場合ルール一つとっても、 「FIFAが定義したルールブック」 「該当するゲームの審判が考える違反基準を元にしたルール」 「各プレイヤーが判断するプレイの上でのルール」 「報道を含む観戦のルール」 などのように実世界のオブジェクトが複数存在します。 ＃審判が見えない範囲で手を使って「伝説のゴール」とかはプレイ上でのルール ＃観戦者はコートの中に入らないという「明示的な暗黙のルール」 これらをクラス定義した場合に「ルール」という言葉の スーパークラスと「サッカーのルール」というインタフェースと ゲームに関わる人たちが個別に持つ「振舞い」を定義する子クラスとに モデリングできますよね？こっちはOOAです。 オブジェクト指向の入門書等で実世界の振舞いをOOAで 示すことが「犬はワンワン鳴く」という例えになっているわけです。 今コナンさんが定義したRTPは、分析ではなく設計に区別されるべきだと 思います。オブジェクトとして 「《人生》 《石ころ》 《全角カタカナを半角カタカナにする関数》 」という 例を分析して再定義して、それらをOODすると RTPというソフトウェア（プログラミング）モデルに割り当てることができる。 というのが私がこれまで述べてきた持論の延長にあたります。 [日本語補正] [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-08 17:37 ] [さらに日本語補正]（汗 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-08 17:39 ] [さらに日本語修正]（滝汗 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-08 17:41 ] うひぃ。裁判じゃあるまいし、判例って・・・[訂正 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-08 17:43 ] 元のコナンさんの投稿から読み返してみると、うまく表現できないけど 「《人生》 《石ころ》 《全角カタカナを半角カタカナにする関数》 」 をモデリングした場合、プレイに当たる上記の各クラスを 作戦のインタフェースとルールのスーパークラスで定義しただけかも？ そして、《全角カタカナを半角カタカナにする関数》という「振舞い」を オブジェクトとして定義した時点でRTPの各内容に違和感を感じるのだと 思います。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-08 18:05 ] | ||||||||||||||||
|
投稿日時: 2005-02-08 18:31
コナンです。
継承とかも表せたらなと思ったので、きっとそうだと思います 
これだと分析でも設計でもなくなっちゃいますかね？
振舞いっていうのがよく分からないんですよね。耳慣れないというか。 変な話ですけど、「振舞おうとする意思」みたいなのはオブジェクトに なりますか？ #何度もRTPと言ってくれてありがとうございます 
| ||||||||||||||||
|
投稿日時: 2005-02-08 21:00
本田＠スミテムです。
お騒がせしております。 実は、未記入様の例示を拝読するほどに、私には、未記入様がA型(振舞のみ)ではなくB型(状態、振舞)なのではないかと判断せざるを得ず、頭が混乱しておりました。 何度読み返しても、未記入様は、ご自分の投稿の中で、「状態」を前提に「振舞」を説明されていらっしゃるように感じるのです。 例えば、冒頭の
です。 「石が存在した」ことこそ、まさに「状態」です。 未記入様は、「石が存在した」＝「状態」を前提にして、「丸さ」や「転がり落ちる」といった「振舞」を説明されていませんか。 #石が存在しなければ転がらないですよね。 次に、
です。 これも、未記入様は、石が「坂道に存在する」という「状態」を前提に「転がり落ちる」という「振舞」を説明されていませんか。 #平地だったら転がらないし、前提が無ければ転がるかどうか不明ですよね。 さらに、
です。 これも同様で、未記入様は、「存在」＝「状態」を前提に「振舞」を説明されていませんか。 #これも、存在しなければ確かに振舞わないですよね。 #なお、ここでいう「存在」はオブジェクト自身の「存在」です。観察者のではありません。 つまり、未記入様ご自身が、「存在」＝「状態」を前提に「振舞」を説明されているのではないでしょうか。 私には、未記入様が、(少なくとも無意識では)このことを理解された上で投稿されているように感じており、ゆえに結論(振舞のみ)に違和感を覚えるのです。 以下に、「存在」は「状態」であることをもう一度、説明したいと思います。 #恐らく同様の説明は、これが3度目になります。 ドメイン空間に石が存在していることをB型(状態、振舞)では、 ドメイン空間.石・・・(1) と認識しています。これに対し、A型(振舞のみ)で認識しようとすると、 ドメイン空間.Get石()・・・(2) となるかと思われます。 なるほど、これにより、石の存在が無事「振舞」になりましたと言いたいところなのですが、このときまだ、ドメイン空間の存在を「振舞」に出来ていません。 ドメイン空間の存在を「振舞」にするためには、もう一つ上のオブジェクトを見出してきてその「振舞」を認識するしかなさそうです。 しかし、今度はそのオブジェクトの存在が「振舞」として認識されていません。 全てのオブジェクトを「振舞」で認識するために、(2)はこのまま極限大まで発散せざるを得ないと思われます。 #あるいはトップレベルに「Get何某()」を許可することも出来ますが、 #これはもうオブジェクト指向ではありません。 一方、(1)は石の存在をドメイン空間の「状態」として認識しています。すなわち、モノの「存在」とは、そのモノを内包しているモノの「状態」であるということです。ドメイン空間の存在もより上位のオブジェクトの「状態」と認識すればよいため、「状態」だけ認めれば発散せずに済みます。 #「振舞」がいらないとは言っていません。 #ここではたまたま「振舞」が出てこなかっただけです。 #「状態」と「振舞」の両方が対等に必要です。 #念のため・・・。 この考察は、「振舞」だけでオブジェクトの「存在」を表現しようとすると、どうしても一番上のオブジェクトの「存在」を表現できないということを示唆しています。 私はA型(振舞のみ)がNGである理由として、上記を挙げました。 可能であれば、未記入様、あるいは他のA型(振舞のみ)の方に、「振舞」だけで、オブジェクトの「存在」を例示して頂きたいと願います。 少なくとも、未記入様の書き込み(2005-02-07 12:46)では、例示できておりません。 よろしくお願いします。 | ||||||||||||||||
|
投稿日時: 2005-02-08 23:09
オブジェクトが状態を持たないと言っている訳ではないと思いますよ。 一種の状態機械であるオブジェクトは、状態を持つに決まっています。 ただ、ドメインモデルであっても、その状態を外部に露出しているのではなく、外部からその状態を取得できる訳ではないという事。 そのオブジェクトの状態を知りたければ、そのオブジェクトに適用できる何らかの操作( = 振る舞い)を通じて、状態を取得する必要があるというだけ。
仮想的にルートになるオブジェクトを設定すると、何か問題がありますか? リアルをそのまま表現できるモデルなんてない。モデルはモデル。 また、世界は「リアルの世界」ではなく、どこまでいっても「私が認識した世界」な訳で、例えば自分が世界のルートでも構わないんじゃないですか? そもそも、オブジェクト自体の存在といっても、自分自身がそのオブジェクトを認識しなければ、オブジェクトの存在は問題にならない。現実に存在していたとしても、自分がモデリングする世界にとっては必要ないものです。 唯一無二のモデルなんてない。人それぞれ世界の見方は違う。
ドメイン空間そのものをあらわすルートとなるオブジェクトがアクセサを持っていて、それを通じて世界に存在するオブジェクトにアクセスするのと何が違うんですか? | ||||||||||||||||
|
投稿日時: 2005-02-09 00:53
未記人様の投稿を未記入様と混同して返信してしまいましたので、一旦削除します。
#微妙な違いでわかりませんでした。 [ メッセージ編集済み 編集者: 本田＠スミテム 編集日時 2005-02-09 01:04 ] [ メッセージ編集済み 編集者: 本田＠スミテム 編集日時 2005-02-09 01:04 ] | ||||||||||||||||
|
投稿日時: 2005-02-09 01:19
改めまして、未記人様。
本田＠スミテムです。
A型の方にとっては、ルートオブジェクトを「振舞」として認識できない点が苦しいのではないかと思っています。 全てを「振舞」のみで認識したかったのに、ルートオブジェクトだけは例外というように、ロジックに例外を認めるのは、私の場合それなりの理由を必要とします。 #つまり、私は例外を飲み込むのが苦痛なのです。 他にさしたる実害はないかと・・・。 #というより、どんな実害があるかは具体的に自分の中でまとまっておりません。
これには大いに同意します。 世界の見方は、人それぞれ独自で構わないし、同じものを見ても同じモデルにはならないでしょう。 私は、認識方法の違いについてまで、NGを出すつもりはありませんし、出せるとも思っていません。 A型とB型の違いを認識方法の違いと考えていたときには、両者の存在を認めておりました。 そして今でも、なるべくであれば、A型の方にはA型の構造の正しさを主張していただきたいと思っております。 #だからこそ、「振舞」だけでオブジェクトの「存在」を例示してほしいのです。 というのは、現実として、A型オブジェクト指向が今日まで大勢を占めてきた背景には、それなりの理由＝正しさがあったのではないかと考えるからです。 しかしその逆に、正しくないのであれば、例外を許容するように甘んじるのではなく、正しい姿に変化してほしいと願います。
という問いには、前のご質問も総括して、「ルートオブジェクトだけ例外的に「振舞」ではないことを認めてしまう以外に、さしたる違いも実害もありません。」とお答えします。 しかしながら、私にとっては、例外を認めること自体が受け入れがたいのです。 恐らくスレ主のobject様は、「既存のオブジェクト指向に構造がない」こと自体を問題視しており、「構造基盤を持ったオブジェクト指向を追及しませんか」と問題提起されているのだと私は思っています。 実務上の問題や障害の重大性は、極端な話、2の次です。 そして、私のように例外を受け入れがたい者にとっては、このスレッドの議論が非常に重要になってくるのです。 未記人様でしたら、このケース、例外を許容されますか。それとも、変化を望みますか。 | ||||||||||||||||
|
投稿日時: 2005-02-09 02:21
例外でも何でもないですよ。 ルートに限らず、オブジェクトそのものは振る舞いではない。 オブジェクトは状態と振る舞いを持つ。 状態にアクセスするには何らかの振る舞いを通じて行う。 存在を振る舞いによって示さなければならない理由がわかりません。 状態を振る舞いで取得するなら、存在を振る舞いで取得しなければならないんですか? ルートとなるオブジェクトを振る舞いによって取得しなければならないという訳ですか? 別に例外とは感じないのですが。ルートの存在は所与の前提。 じゃあ、オブジェクトの存在をドメイン空間の状態としてあらわすのであれば、ドメイン空間の存在は何の状態としてあらわされるんですかね? # 余談ですが、ルートイコール自分なら、それこそ Cogito, ergo sum. ですかね。 # 1秒前の自分と現在の自分の連続性とか言い始めるときりがないので
例外と感じない。 それでも例外だと言われるのであれば「ああそう思うのなら思ってください。で、それで?」 | ||||||||||||||||
|
投稿日時: 2005-02-09 02:37
特に誰かに対する意見というわけではないのですが…。
ここらへん「安易にproperty setを使うべからず」という教訓が引き出せそうですね。 Windowクラスの例ですと、情報としてはたしかに左、右、幅の３つが観測されるけども、 線形独立な情報としては本質的にそのうちの２つのみ。 ゆえに（左、右、幅）の３つでは自由度が生まれてしまう。 振る舞い「移動」や「サイズ変更」は、前者は幅固定、後者は左or右を固定、という形で 自由度が減るので問題なく実装できますけど、（左、右、幅）のどれか１つへの property set では自由度を減らさないまま１つの情報をセットしようとするので、 どうしても自由度の分だけ、実装者の恣意が入ってしまう…。 私は（左、右、幅）へのproperty setを行う順序は気にしたくないですね。 それよりかは動作の明快な振る舞いがあることを望みます。 ただ「独立な情報はどれか」を実装者が恣意的に選んでもかまわないケースもありますね。 たとえば、オブジェクトの情報を外部ストレージに保存するケースです。 Windowクラスの実装者が（左、右、幅）のうち、とにかくどれか２つの情報を 独立な情報として指定してくれれば、それがどれであろうとも外部ストレージへの 保存・復元という目的は達成できます。 さて、この観点で .NET Framework クラスライブラリをみてみると…… Controlクラスでは、Left、Widthプロパティはget/setありで、 Rightプロパティはgetのみ。しかもMoveメソッドはなし。 Left,Widthにしかsetがないのは、実装者の恣意が入ってもかまわないケース、として 納得できますが、Moveメソッドなしですか…… …………なんか、微妙だなぁ（笑 「安易にproperty setに頼ると振る舞いを抽出し損ねる」と言えるかもしれませんね。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.