＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-07 23:32
本田＠スミテムです。 私は逆に、未記入様のお話の展開が自分の中で？になってしまいました。 恐れ入りますが、確認させてください。
石の話で未記入様が例示されているもの、すなわち、私などが「情報(状態)」と認識し、未記入様が「振舞」と認識するものの例は、石の「丸さ」でよろしいですか。 他にも言葉がいろいろありますので、以下が例示ではないことも確認させてください。 ・石自身の「存在」 ・石が「坂道に存在する」こと ・石が「転がり落ちる」こと ・石の種類、花崗岩、安山岩、閃緑岩、その他多数 ・石が「凝固する」こと ・石を構成する「原子」 ・石の形や色 ・石が過去に受けた影響 また、もし、これらも例示であれば、全て「振舞」なのかどうかお教えください。 (追加)石の「丸さ」と同じものもあればお願いします。 [ メッセージ編集済み 編集者: 本田＠スミテム 編集日時 2005-02-08 00:35 ] | ||||||||
|
投稿日時: 2005-02-08 06:04
ぐっちょ、も〜にんぐ。はにまるです。
いえ、お陰様で質問が通じ難い文書である事が判りました。 多分、これで理解頂けるかな？と思っています。
はい、ここまで理解出来てはいますが、しかしこの理論では 「要素→データ」、「集合→フィールド」、「写像→関数」 までしか納得出来ませんし、 ここからメソッドとプロパティに押上げる理論は提示されていません。 例えば「髪の色」と「身長」の要素同士からは何らかの関係を見出す事は出来ません。 {黒、白、金}は「髪の色」集合の要素です。 {1.6m、1.7m、2m}は「身長」集合の要素です。 メソッド＝振舞とするならば、１メソッドはメソッドが所属するオブジェクト内の全要素が扱えますから {1.6m、1.7m、2m、黒、白、金}の集合概念が存在します。 しかしこの集合概念は数学上、意味はあるのでしょうか？ また「髪の色」と「身長」を兼ね合せて新たな情報元を創出する行為は数学なのでしょうか？ 以上の疑問を頂きました。 _________________ 人生変わっちゃうかもよ?OFF会参加者募集中今考えるな、参加してから考えろ。 | ||||||||
|
投稿日時: 2005-02-08 10:24
コナンです。
プロパティといえば右クリックしか思い浮かばない人なので、雰囲気で答えてしまいました。 すみません 
この部分がひっかかりました。 {黒、白、金}の黒や白は「髪の色」集合の要素ですが、オブジェクト内の要素ではないと思います。 「髪の色」集合はプログラム的に言うと、ある関数の引数にとりうる値のことです。 例えば全角カタカナを半角カタカナにする関数の場合は、引数は文字列ですよね。 この文字列を集合として考えると、{ア、アア、アアイ、アアウ、…}のようなかんじですよね。 で、写像を介して{ｱ、ｱｱ、ｱｱｲ、ｱｱｳ、…}の集合の中から対応するやつが一つ選ばれるイメージですかね。 なので、髪の色と身長で何かしたい場合は、引数を2つにすればいいと思います。
数学かどうかは正直よく分からないんですけど、数学的にアプローチすることによって 何かがスッキリするような気がします 
| ||||||||
|
投稿日時: 2005-02-08 12:30
そうですね関数の引数にとりうる値の話ですよね。 主な疑問だけを話せばよかったと反省しています。 主は前投稿の前半です。 _________________ 人生変わっちゃうかもよ?OFF会参加者募集中今考えるな、参加してから考えろ。 | ||||||||
|
投稿日時: 2005-02-08 12:52
objectです。
えっ、そうなんですか？(^^ゞ 私は、議論できる共通のベースを模索する為に、これまで質問をして来た積もりでした。 そして、「抽象データ型」に関しては、基本的な一致点を見出したのですが、 「オブジェクトとドメイン空間」に関する部分では、認識の違いが大きいと判断してしまいました。 それで、前回のレスを差し上げた訳です。 何か、私の早合点だった様で、謝ります！<(_ _)> それでは、少し私の観点から、話をします。 最初に、 「H2さん」は オブジェクト指向という概念が生まれる前にも「ドメイン空間」と言えるものがあった というお考えの様ですが、 私が考えている「ドメイン空間」は、あくまで「構造」を持っている空間です。 #「ソフトウエア空間」に於ける「抽象データ型」迄の解釈を、カテゴリ「フィールド、ファンクション」で行って #みる事はとても意味があると思いますが、ここでは保留します。 次に、 「オブジェクト指向」のベースが「抽象データ型」である という点に関しては、私も同じ考えです。 しかし 「抽象データ＋継承・多相」 を考えた場合、確かに 「機能的・構造的」には「オブジェクト指向」の「フレーム」に近いものが実現出来る と思います。 でも、これでは、あくまで「ソフトウエア空間」上の「フレーム」であり、 「オブジェクト指向」つまり「ドメイン空間」上の「フレーム」にはならない と考えています。 また、1つ気になる点として >私がソフトウェア空間の概念で話をしているのであれば、もっとJavaだとか >.NETなどの実装言語を使った説明をしていると思います。 「ソフトウェア空間」か「ドメイン空間」かは、話題の「抽象・具象性」とは無関係だと思いますよ？ それから、これは独り言ですが、 「Java」で「フィールド」がクローズアップされましたが、 「C、C++」では、「左辺値、右辺値」がベースでは無かったか？ なんて思いが少ししてるんですよね。 #私も掲示板の限界はヒシヒシと感じています。 #でも、これは考え方によっては、とても良い「言葉での対話の訓練」になりますよね？(^^ゞ #今回初めて「H2さん」と話をさせて頂いて、じっくり客観的な話が出来る方である事が十分に分かりました。 #機会があれば、方法論その他を含めて、色んな話をジックリとしてみたいと私も思っています。 #今後共宜しくお願いします。 [ メッセージ編集済み 編集者: object 編集日時 2005-02-08 13:00 ] | ||||||||
|
投稿日時: 2005-02-08 13:06
斜めにしか読んで無いので詳細はわかりませんが なんだかエライコトになってるような・・・
石の状態を調べるのに、どのような「振る舞い」を用いますか？ ・目で見ますか？ ・叩いて音をききますか？ ・握ってみますか？ ・舐めてみますか？（きちゃない OOAにおける石に関する情報はすべて受けてのものです。 OODにすると意味が変わってしまいますが・・・ OODでは石を扱う範囲（赤い石と黒い石など）で抽象化し、 よりプログラムしやすいように最適化（リファクタリング）するのが 良いと思います。 しかし、要件を提起した人がOODの「範囲」が正しくないと指摘することも あると思います。その場合はOOAに具体的にオブジェクトを追加してもらって、 再度OODに入ることに・・・ なので、全てをOOAしてその後にOODすると手直しの範囲が[とてもとても強そう]な ことになってしまいます。そのため、あじゃいるとかXPとかいう手法が 出てくるのですが・・・エンドユーザがついてこないとマッタク意味がありません。 | ||||||||
|
投稿日時: 2005-02-08 14:11
いえ、ここまでは確認でして、素朴な質問はこれからです。（笑） まず、「プロパティが重要」と言われる一つの理由は上記にありますね？ では、このＷＩＮＤＯＷクラスの例ですと「右の位置は左の位置プラス幅」というルールは何故に情報側に必要なのでしょうか？ ・情報：左、右、幅の３つ ・振舞１：移動（方向 as 角度，移動量 as 相対座標） これにより左と右が変更される。 ・振舞２：サイズ変更（方向 as 角度，変更量 as 長さ） 方向が左なら左と幅が、方向が右なら右と幅が変更される。 振舞２には暗に「幅は左と右の距離」というルールがもりこまれていますが、これだと「破綻している」のですね？ もう一つ、「これらのルールが振舞にあってはならない」だとしても、「情報になければならない」とはならないと思います。例えば情報・振舞以外の別の要素であってもよいはず。 ＷＩＮＤＯＷクラスのフィールドを２つにするなら、左と右の方がしっくりきませんか？要するにルールは、 ・「右の位置は左の位置プラス幅」 ・「幅は左と右の距離」 のどっちが適切か？ということなのですが．．． 合理化しようとするとこの手の問題が出てこないですかね？ | ||||||||
|
投稿日時: 2005-02-08 16:49
コナンです。
↓モデリングについての考えを背景からまとめてみました。 オブジェクト指向の入門書とかに、「犬はワンワン鳴く」、「ブルドッグは犬クラスを 継承しているのでワンワン鳴く」のようなたとえ話ってよく載ってますよね。 僕もこういう本を読んで勉強したことがあるんですけど、「犬クラスっていったい…」と 思ってなかなか進まず、悶々としていました。 でも犬じゃなくてサッカーに例えてみたら理解できた(ような気がする)ので、 ここで発表してみます。 特徴は物事をルール、作戦、プレーヤーに分けることです。 【ルール】 作戦とプレーヤーを制限する事柄です。 プレーヤーが存在するための世界と言えます。 ・11人対11人 ・手を使っちゃダメ など 【作戦】 プレーヤーを制限する事柄です。 プレーヤーの意思とは無関係に存在する目的のようなものです。 ・3-5-2 ・4-4-2 など 【プレーヤー】 この人が主役というか主体です。（インスタンス？） ルールと作戦に縛られながらも精一杯、自分の仕事をする人です。 ・エースストライカー ・ディフェンダー など 他の例でも示してみます。 《人生》 ルール：いつか死ぬ 作戦：子孫を残す プレーヤー：結婚する 《石ころ》 ルール：万有引力 作戦：地球を形作る プレーヤー：その場所でじっとする 《全角カタカナを半角カタカナにする関数》 ルール：文字コード 作戦：全角カタカナを半角カタカナにする プレーヤー：引数が全角カタカナかチェックする これがオブジェクト指向なのかどうかは分かりませんが、 ビジネスを定義するときなどには役立ちそうです。 もしまだ似たような分析モデル(?)がなければ、ルール(Rule)、作戦(Tactics)、 プレーヤー(Player)の頭文字をとって、RTP分析モデルと命名しようと思います
| ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.