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

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

«前のページへ 13|14|15|16|17|18|19|20|21|22|23 次のページへ»
投稿者投稿内容
tak3
ベテラン
会議室デビュー日: 2004/04/15
投稿数: 80
お住まい・勤務地: 菜の花・銀杏
投稿日時: 2005-02-03 14:38
プロパティとフィールドの違いについて、自分なりに整理してみました。
# まとめの２番煎じというか、具体例を追加しただけですが・・・

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

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

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

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

と、今のところ認識してるのですが、間違いなどありましたらご指摘ください。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2005-02-03 14:41
　functionの定義について、色々考えてみたのですが、
ほとんど全てのリアルドメインでfunction自体が成り立たないという
私のモデリングに関する考え方の結論に達しました。

　なぜなら、functionのパラメータもしくはリターンバリューのメソッド=function
という実装が可能であり、かつ、methodとして実装するほうがリアルドメインでの
ビフェィヴィアにマッチするからです。

　そのため、モデリングドメインでもfunctionという定義があっても
無意味で実装担当者を惑わせるだけではないかと思います。
ただし、デザインパターンの中にはfunctionを許容する実装があるかもしれません。

その場合にはモデリングドメインではなくプログラムドメインで、
functionとして実装すればよいと思います。
nak2k
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 86
投稿日時: 2005-02-03 16:09
一般的なファンクションは、
引用:

未記人さんの書き込み (2005-02-03 08:36) より:
普通はファンクション=「副作用を持たず、戻り値を持つ(べき等な)サブルーチン」では (プロシージャと対比されるところの)。

これで問題ないと思います。

ただ、今回のobjectさんの主張ではそういう形では使ってないようです。
「XXXXという概念についてここでは便宜上ファンクションと呼ぶ」というような感じです。
（関数というよりは機能とでも訳したほうがいいかもしれません）

もう一度、objectさんのまとめについて
リアル空間→ドメイン空間（１、２）→ソフトウェア空間
の順に見てもらえませんか？＞zaxx_MDさん
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2005-02-03 16:14
若干補正してリプします。

引用:

k-nakさんの書き込み (2005-02-03 16:09) より:
ファンクション=「副作用を持たず、戻り値を持つ(べき等な)サブルーチン」
これで問題ないと思います。

リアル空間→ドメイン空間（１、２）→ソフトウェア空間
の順に見てもらえませんか？＞zaxx_MDさん


「副作用を持たず、戻り値を持つ」
とは
「戻り値にとっての副作用を持っている」
という事と同義です。

どう考えてもリアルドメインでは成り立ちません。
ただ、Object a = b.newInstance()のような慣例的な書き方をする
ソフトウェアドメインが存在するのも事実です。

[編集追加]
しかしリアルドメインでのオブジェクトは
Object a = new A()であるべきです。

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 16:16 ]
コブラ
ぬし
会議室デビュー日: 2003/07/18
投稿数: 1038
お住まい・勤務地: 神奈川
投稿日時: 2005-02-03 16:24
具体的には、 投稿日時: 2005-02-02 23:52 のあんたの書き込み＞るぱん
未記人
ベテラン
会議室デビュー日: 2004/08/21
投稿数: 70
投稿日時: 2005-02-03 16:39
引用:

zaxx_MDさんの書き込み (2005-02-03 16:14) より:
「副作用を持たず、戻り値を持つ」
とは
「戻り値にとっての副作用を持っている」
という事と同義です。

どう考えてもリアルドメインでは成り立ちません。

関数 (function) かどうかは、呼出し先に対して非破壊的かどうかだけでしょ。
呼出し元で、結果をどこに代入しようがどうしようが関係ない。

残高照会すると事で残高が変化しますか?
天気予報を調べると予報が変化しますか?
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2005-02-03 16:45
引用:

未記人さんの書き込み (2005-02-03 16:39) より:
関数 (function) かどうかは、呼出し先に対して非破壊的かどうかだけでしょ。
呼出し元で、結果をどこに代入しようがどうしようが関係ない。

残高照会すると事で残高が変化しますか?
天気予報を調べると予報が変化しますか?


口座オブジェクトの残高照会メソッド
テレビオブジェクトの天気予報番組オブジェクトを目オブジェクトで見るメソッド

＃天気予報っていう言葉は結構色々なパターンがあるねぇ

[修正]
テレビなのに聞くって・・・

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 16:47 ]

見るなら目だよ・・・もちつけオレ

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 16:48 ]

#そういえば昔他行の口座だと残高照会だけでも預金から手数料引かれなかった？

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 16:51 ]

　もっというと、残高照会手順というオブジェクトも
存在しうると思う。
　メタファとして、functionという考え方は
オブジェクト指向分析そのものを否定するものだと思う。
　手続き指向のシステム開発しかできない人たちは
理解できないと思うけど。

[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 17:21 ]

　ああ、もう一つ忘れてた。基本的なことですみませんが
superクラスのフィールドにのみアクセスするメソッドは
一見するとfunctionに見えるかもしれませんが、
明らかにmethodです。


[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-02-03 17:41 ]
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2005-02-03 17:41
誰も振舞・情報の定義をしないから妄想してみました。


振舞とは依頼側にデータがあり、請負側がデータ意義を定義をする事。
情報とは請負側にデータがあり、依頼側がデータ意義の定義をする事。

客観的に見た振舞は、
　　依頼側が請負側に要求をする行為によって発生（または事前定義の起動）し
　　起動結果によって内部的影響と外部的影響が発生する。

　　・内部的影響とは、請負側の属性変更である。
　　・外部的影響とは、依頼側及び第三者に振舞や情報を求める事。
　　　または依頼側に情報元（データ）を返す事である。

客観的に見た情報は、
　　依頼側が請負側の属性を参照する（情報源の取得）事であり
　　請負側に一切の自発性は許さない。
　　よって
　　依頼側が請負側に属性の設定を要求する事は振舞であり、
　　請負側の自発性を伴う属性の参照も振舞である。

例えば、
私がＡさんに性別を伺いその答えも貰った場合は、振舞であり
Ａさんの「服装や言葉使い」から私が性別を決め付けた時は情報である。


[ メッセージ編集済み 編集者: はにまる 編集日時 2005-02-03 17:43 ]
«前のページへ 13|14|15|16|17|18|19|20|21|22|23 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）