@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

「UML」を初めとする現在の「モデリング言語(手法)」の問題点は?

投稿者投稿内容
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2005-02-03 17:49
すみません、定義についてはよくわからないです。

引用:

はにまるさんの書き込み (2005-02-03 17:41) より:
私がAさんに性別を伺いその答えも貰った場合は、振舞であり
Aさんの「服装や言葉使い」から私が性別を決め付けた時は情報である。



ので、「人は例によってのみ理解する」ということで

私.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 ]
未記人
ベテラン
会議室デビュー日: 2004/08/21
投稿数: 70
投稿日時: 2005-02-03 18:10
引用:

zaxx_MDさんの書き込み (2005-02-03 16:45) より:
 メタファとして、functionという考え方は
オブジェクト指向分析そのものを否定するものだと思う。


とりあえず、CLOSとかSchemeとかで遊んでみて、functional programming ってものに触れてみてください。

# LispはFPじゃないっていう人も多いけど
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-02-03 19:41
引用:

コブラさんの書き込み (2005-02-03 16:24) より:
具体的には、 投稿日時: 2005-02-02 23:52 のあんたの書き込み>るぱん


これね?
引用:

見返してどうするの?

それと、疑念の払拭はどうするんですか?


これと
引用:

自分の過去の言動を、「禊は済んだ」とばかりにイケシャァシャァと他人事として捉える
のは相変わらずですか?>るぱん


これがどのように関係してくるの?
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-02-03 20:07
引用:

tak3さんの書き込み (2005-02-03 14:38) より:
プロパティとフィールドの違いについて、自分なりに整理してみました。
# まとめの2番煎じというか、具体例を追加しただけですが・・・

・職業は自由に変更できる。
・生年月日は途中で変わるようなことは無い。
・年齢は生年月日から自動で求められる(派生属性)

コード:
分析                 設計/実装 (A) UML             (A') UML
┏━━━━━━━┓   ┏━━━━━━━┓        ┏━━━━━━━┓
┃ 職業     ┃   ┃ -職業       ┃       ┃ +職業    ┃
┃ 生年月日   ┃   ┃ -生年月日   ┃       ┃ -生年月日  ┃
┃ /年齢    ┃   ┣━━━━━━━┫  or    ┣━━━━━━━┫
┣━━━━━━━┫   ┃ +get職業     ┃        ┃ +get生年月日┃
┃       ┃   ┃ +set職業     ┃        ┃ +get年齢  ┃
┗━━━━━━━┛   ┃ +get生年月日 ┃        ┗━━━━━━━┛
                    ┃ +get年齢    ┃
                    ┗━━━━━━━┛
                                      (B) NOT UML
                     ┏━━━━━━━┳━━━━━━┓
                     ┃ +RW 職業   ┃ -職業     ┃
                     ┃ +R 生年月日  ┃ -生年月日 ┃
                     ┃ +R 年齢     ┃           ┃
                     ┣━━━━━━━╋━━━━━━┫
                     ┃             ┃           ┃
                     ┗━━━━━━━┻━━━━━━┛


(A)と(A')の職業についての視点 -> フィールドとプロパティは同じ
年齢の表現ついての視点 -> フィールドとプロパティは違う
(年齢はメソッドでない表現方法を取るべき)

UMLに対する問題点?
1.年齢が属性だったり操作だったりする(きれいにマッピングできない)
2.アクセッサは隠蔽されたフィールドへのアクセスするため機能であり、操作じゃない。
などなど・・・まとめて
-> ドメイン空間とソフトウェア空間のマッピングに不整合がある。

と、今のところ認識してるのですが、間違いなどありましたらご指摘ください。


1に対しての認識
UMLはツールである。
属性であるか操作であるかは定義してから始めれば良いと思う。

反例:最初に属性として定義していたが、振る舞いであったことに気が付いた場合はどうするべきか?

→リファクタリングするべきなのでは無いでしょうか?

2に対しての認識
アクセッサだけがメソッドではなく、アクションメソッドを実装するのはどうでしょう?


不整合に対しての認識

もし、不整合が許容できなくなるのであればリファクタリングしませんか?

感想:
UMLを使う上で定義があれば使いこなせるのではないんじゃなかろうか?
functionの話を聞いて思ったことは、
一度に全てまとめてごそっと片付くお絵かきツールが欲しい・・・。
と言うことを要求されている気がします。

以前にも申し上げましたが、
オブジェクトを情報と振舞(属性と振舞etc)で分けて考えて
後から構築するのではいかがでしょうか?

こんな風になりませんかね?
コード:
┏━━━━━━┓
┃-職業       ┃
┃-生年月日   ┃
┣━━━━━━┫
┃+get職業    ┃
┃+get生年月日┃
┃+get年齢    ┃
┃+転職       ┃
┃+take誕生日 ┃
┃-change年齢 ┃
┗━━━━━━┛
無理にアクセッサつけなければいけないと言う問題は無いと思います。
確かに、プロパティに慣れてしまうと不便に思うかもしれません。



プロパティは便利ですけど、
頼りすぎて痛い目見た事があるので(MSXMLのDOMで)
わけのわからないエラー(メモリがreadされませんでしたetc)
食らってたので
アレルギー出てるのかも知れないです。

やっぱり、リファクタリングの手法を早く身に付けなくては・・・
と思いました。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-02-03 20:14
引用:

zaxx_MDさんの書き込み (2005-02-03 17:49) より:
すみません、定義についてはよくわからないです。

引用:

はにまるさんの書き込み (2005-02-03 17:41) より:
私がAさんに性別を伺いその答えも貰った場合は、振舞であり
Aさんの「服装や言葉使い」から私が性別を決め付けた時は情報である。



ので、「人は例によってのみ理解する」ということで

私.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 ]


ふと思ったこと。

登場人物

リンゴ

私.食べる(リンゴ)
リンゴ.食べられる(私)

となるのでしょうか?
この場合、私の持つメソッドとリンゴの持つメソッドはどう繋がるのでしょうか?
らぶま
常連さん
会議室デビュー日: 2004/10/21
投稿数: 32
投稿日時: 2005-02-03 21:03
興味深く拝見しています。

素朴な疑問です。とりあえず書いてみます。
プロパティとメソッドは独立した概念なのでしょうか(why)?
プロパティを認めた場合、メソッドは概念として必要ですか?

プロパティ = f(フィールド、ファンクション)
メソッド = g(フィールド、ファンクション)
なら、fとgが同値な関係にはなりえないのでしょうか?

さらに追加するなら、(議論を逆戻しするようで恐縮です)
fやgがファンクションではいけませんか?
理由:概念の単純化(るぱんさんの言うリファクタリングをしなくていい様に)。


>objectさん
オブジェクト指向における「構造」が「代数」的である理由が分かりません。
何度も主張されているのですが、申し訳ない限りです・・

[ メッセージ編集済み 編集者: らぶま 編集日時 2005-02-03 21:21 ]
本田@スミテム
常連さん
会議室デビュー日: 2004/01/22
投稿数: 21
お住まい・勤務地: 東京
投稿日時: 2005-02-03 21:06
こんにちは。
本田@スミテムです。

引用:

objectさんの書き込み (2005-02-02 22:31) より:
objectです。

>本田@スミテムさん
今までの中では、最も私の考えを理解して頂いている様で、私も嬉しいです。



恐縮です。
大筋は理解できていると思うのですが、消化不良している部分もあります。
それは、今後の議論の中で消化していきます。

引用:

引用:

本田@スミテムさんの書き込み (2005-02-02 03:57) より:

結論として、私は、オブジェクトに「情報・振舞」を知覚することが出来るのであれば、多くの方がobject様の主張に同意できるのではないかと考えます。
また、私は認識の違いと判断してしまいましたが、もしobject様が、オブジェクト指向A(振舞のみ)はNGで、オブジェクト指向B(情報・振舞)しかOKであり得ない事を何かの形で示して頂けたら、この主張の理解者は増え、大きなストリームになるかもしれないと予感しています。


今は、時間が取れませんので、
私のレス(投稿日時: 2005-01-06 12:59)
「.NET開発者のためのリファクタリング入門について」
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=17496&forum=7&start=8
を取り敢えず参照して頂きたいと思います。
表現が完全ではありませんが、参考にはなると思います。
私は
「集合、写像」が基本で、その具象表現として「情報・振舞」があると思っています。
#簡単ですが、参考にして下さい。



拝読しました。
他スレからの引用になりますが、以下の部分が私の理解の助けになりそうです。

引用:

objectさんの書き込み (2005-01-06 12:59) より:
オブジェクト指向の説明の中で
「情報、振舞」
というセットが、とても簡単(安易)に導入されています。
しかし、この「情報、振舞」という「カテゴリ」は極めて本質的で、
もし、これに近い概念を取り上げるなら、それは
「集合、写像」の概念(代数系)
だと思います。
#しかし、「代数系」を学んでみても、何故「集合、写像」という「カテゴリ」を導入するかは理解出来ないでしょう。
#「集合、写像」は、それ位に基本的な「概念セット」です。
#安易に、常識レベルでは判断しない方が良いと私は思います。



『ソフトウェア空間においても、「集合、写像」が基本で、その具象表現として「データ・アルゴリズム」がある。』

もし、この表現が正しければ、私は理解できていると思います。

「集合、写像」は、モノの構造を認識するときの基本フレームであり、もっと大げさに言えば『構造とは「集合、写像」である。』と理解しました。
何らかの構造を持ったモノは「集合、写像」の概念によって理解できると言えます。
「集合、写像」が基本ならオブジェクト指向B(情報・振舞)が極めて自然に導出されますね。

これを踏まえて、以下、オブジェクト指向A(振舞のみ)がNGである理由に挑戦してみます。

もしもドメイン空間を「振舞」だけで認識するとして、「では、どうやってオブジェクトを切り出すつもりですか。」と問いかけてみます。
恐らく「振舞」だけでは、オブジェクトを切り出すことが出来ないと思われます。
そこで、オブジェクト指向A(振舞のみ)では、特別にドメイン空間の直下のオブジェクトだけを暗黙的に「情報」として認識することで切り出します。
オブジェクトの中にあるオブジェクトは、「振舞」として認識します。
もちろん、オブジェクトの「振舞」は「振舞」として認識します。
ドメイン空間直下のオブジェクトを切り出すときには、暗黙的に「情報」として認識しているのに、オブジェクトの中のオブジェクトの場合は「振舞」として認識するというのは、少し不自然に感じます。

こんな感じでよろしいでしょうか。

#異論・反論おありでしょうが、まずスレ主様のコメントを頂いてからとさせてください。 > ALL
#そもそも、スレ主様がNOならば、この場で本件を議論しても無意味ですから・・・。
未記人
ベテラン
会議室デビュー日: 2004/08/21
投稿数: 70
投稿日時: 2005-02-03 22:26
引用:

るぱんさんの書き込み (2005-02-03 20:07) より:
反例:最初に属性として定義していたが、振る舞いであったことに気が付いた場合はどうするべきか?

→リファクタリングするべきなのでは無いでしょうか?

--

不整合に対しての認識

もし、不整合が許容できなくなるのであればリファクタリングしませんか?

--

やっぱり、リファクタリングの手法を早く身に付けなくては・・・
と思いました。


いや、そういう実装レベルの事を四の五の言ってるから話しが通じないんですよ。
「C#等のプロパティは単なる実装上のシンタックスシュガーに過ぎない」という意見に対して、o氏は「プロパティはドメインモデル上の重要な概念だ、ドメインモデルの構造をプログラムの構造に写像するにあたって不可欠なものだ」と言い続けてるんですから。

私はドメインモデルと設計モデルと実装モデルで揺れがあるのは当たり前だと思ってるので、何とも感じませんが。上流から下流までシームレスなんてまだ夢物語。

スキルアップ/キャリアアップ(JOB@IT)