@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は?
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-03 17:49
すみません、定義についてはよくわからないです。
ので、「人は例によってのみ理解する」ということで 私.Aさんの情報を更新(性別 := 私.listen(A.性別を伝える())) 私.Aさんの情報を更新(性別 := 私.性別を想像(私.see(A.見せている服装) , 私.listen(A.話()))) って事ですよね? っと・・・想像するときは「私」に話しているとは限らないし、 定義してませんでしたので修正。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 17:53 ] 性別 = 私.Aさんの情報.人.性別 というフィールドの前提定義が抜けてますた。 っと、この場合 私->Aさんの情報->人->性別という書き方が正しいのかな・・・ javaだとこの辺が統一されてて楽だと思いました。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 18:03 ] | ||||||||||||||||
|
投稿日時: 2005-02-03 18:10
とりあえず、CLOSとかSchemeとかで遊んでみて、functional programming ってものに触れてみてください。 # LispはFPじゃないっていう人も多いけど | ||||||||||||||||
|
投稿日時: 2005-02-03 19:41
これね?
これと
これがどのように関係してくるの? | ||||||||||||||||
|
投稿日時: 2005-02-03 20:07
1に対しての認識 UMLはツールである。 属性であるか操作であるかは定義してから始めれば良いと思う。 反例:最初に属性として定義していたが、振る舞いであったことに気が付いた場合はどうするべきか? →リファクタリングするべきなのでは無いでしょうか? 2に対しての認識 アクセッサだけがメソッドではなく、アクションメソッドを実装するのはどうでしょう? 不整合に対しての認識 もし、不整合が許容できなくなるのであればリファクタリングしませんか? 感想: UMLを使う上で定義があれば使いこなせるのではないんじゃなかろうか? functionの話を聞いて思ったことは、 一度に全てまとめてごそっと片付くお絵かきツールが欲しい・・・。 と言うことを要求されている気がします。 以前にも申し上げましたが、 オブジェクトを情報と振舞(属性と振舞etc)で分けて考えて 後から構築するのではいかがでしょうか? こんな風になりませんかね?
プロパティは便利ですけど、 頼りすぎて痛い目見た事があるので(MSXMLのDOMで) わけのわからないエラー(メモリがreadされませんでしたetc) 食らってたので アレルギー出てるのかも知れないです。 やっぱり、リファクタリングの手法を早く身に付けなくては・・・ と思いました。 | ||||||||||||||||
|
投稿日時: 2005-02-03 20:14
ふと思ったこと。 登場人物 私 リンゴ 私.食べる(リンゴ) リンゴ.食べられる(私) となるのでしょうか? この場合、私の持つメソッドとリンゴの持つメソッドはどう繋がるのでしょうか? | ||||||||||||||||
|
投稿日時: 2005-02-03 21:03
興味深く拝見しています。
素朴な疑問です。とりあえず書いてみます。 プロパティとメソッドは独立した概念なのでしょうか(why)? プロパティを認めた場合、メソッドは概念として必要ですか? プロパティ = f(フィールド、ファンクション) メソッド = g(フィールド、ファンクション) なら、fとgが同値な関係にはなりえないのでしょうか? さらに追加するなら、(議論を逆戻しするようで恐縮です) fやgがファンクションではいけませんか? 理由:概念の単純化(るぱんさんの言うリファクタリングをしなくていい様に)。 >objectさん オブジェクト指向における「構造」が「代数」的である理由が分かりません。 何度も主張されているのですが、申し訳ない限りです・・ [ メッセージ編集済み 編集者: らぶま 編集日時 2005-02-03 21:21 ] | ||||||||||||||||
|
投稿日時: 2005-02-03 21:06
こんにちは。
本田@スミテムです。
恐縮です。 大筋は理解できていると思うのですが、消化不良している部分もあります。 それは、今後の議論の中で消化していきます。
拝読しました。 他スレからの引用になりますが、以下の部分が私の理解の助けになりそうです。
『ソフトウェア空間においても、「集合、写像」が基本で、その具象表現として「データ・アルゴリズム」がある。』 もし、この表現が正しければ、私は理解できていると思います。 「集合、写像」は、モノの構造を認識するときの基本フレームであり、もっと大げさに言えば『構造とは「集合、写像」である。』と理解しました。 何らかの構造を持ったモノは「集合、写像」の概念によって理解できると言えます。 「集合、写像」が基本ならオブジェクト指向B(情報・振舞)が極めて自然に導出されますね。 これを踏まえて、以下、オブジェクト指向A(振舞のみ)がNGである理由に挑戦してみます。 もしもドメイン空間を「振舞」だけで認識するとして、「では、どうやってオブジェクトを切り出すつもりですか。」と問いかけてみます。 恐らく「振舞」だけでは、オブジェクトを切り出すことが出来ないと思われます。 そこで、オブジェクト指向A(振舞のみ)では、特別にドメイン空間の直下のオブジェクトだけを暗黙的に「情報」として認識することで切り出します。 オブジェクトの中にあるオブジェクトは、「振舞」として認識します。 もちろん、オブジェクトの「振舞」は「振舞」として認識します。 ドメイン空間直下のオブジェクトを切り出すときには、暗黙的に「情報」として認識しているのに、オブジェクトの中のオブジェクトの場合は「振舞」として認識するというのは、少し不自然に感じます。 こんな感じでよろしいでしょうか。 #異論・反論おありでしょうが、まずスレ主様のコメントを頂いてからとさせてください。 > ALL #そもそも、スレ主様がNOならば、この場で本件を議論しても無意味ですから・・・。 | ||||||||||||||||
|
投稿日時: 2005-02-03 22:26
いや、そういう実装レベルの事を四の五の言ってるから話しが通じないんですよ。 「C#等のプロパティは単なる実装上のシンタックスシュガーに過ぎない」という意見に対して、o氏は「プロパティはドメインモデル上の重要な概念だ、ドメインモデルの構造をプログラムの構造に写像するにあたって不可欠なものだ」と言い続けてるんですから。 私はドメインモデルと設計モデルと実装モデルで揺れがあるのは当たり前だと思ってるので、何とも感じませんが。上流から下流までシームレスなんてまだ夢物語。 |