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

- PR -

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

«前のページへ 17|18|19|20|21|22|23|24|25|26|27 次のページへ»

投稿者

投稿内容

nak2k: ベテラン; 会議室デビュー日: 2003/07/17; 投稿数: 86

投稿日時: 2005-02-04 18:23

以前から「モデリングの際のちょっとした落とし穴」と思っていたことが話題に上がりましたのでレスします。

引用:

本田＠スミテムさんの書き込み (2005-02-04 15:28) より:
setterについては、とてもいいところを指摘されたと思います。
実は、私も今のところ、ソフトウェア空間におけるsetterやproperty setは「振舞」ではないかと考えています。

#私の消化不良の一つです。

私の今のところの考えでは、
1.ソフトウェア空間における「情報」の写像は、property getのみです。
2.property setは、「振舞」の写像であるmethodのSyntax Sugarです。
ただし、
3.リアル空間では、そもそもproperty setは存在しません。
です。

例えば、リアル空間で

　本田.職業 = 銀行員

という代入はイメージできません。

　本田.転職する(銀行員)

だと思っています。

私は、「リアル空間でもproperty setは存在しうる」と思ってます。
ただし、ここでいう「リアル空間」を厳密には「観測者を定めたときのリアル空間」とした場合です。

たとえば上記の「職業」プロパティについて、カード会社の顧客情報管理システムで考えて見ましょう。
私がカード会社に対して申し込みをすると、カード会社に個人情報として職業も当然記録されます。

knak.職業 = エンジニア

ところがその後の信用調査で、虚偽申請があったことが発覚し、実は無職であったとしましょう。

knak.職業 = 無職
# 注）言うまでもありませんが、あくまで例です

この場合、「リアル空間」における knak.職業は、実は何一つとして変化していないのですが、
「観測者（カード会社）にとってのリアル空間」では、knakの振る舞いなしに
「職業：エンジニア→無職」へと「認識が変化」しています。
この認識の変化に対応して property set を行うのだと思います。

他の見方をすると、たとえばシステム化以前のカード会社の業務を考えれば分かるのですが、
「顧客クラス」に相当するモノは、システム化前では「顧客票」といった書類が考えられます。
書類は記載事項の変更ができるので property set は、性別や年齢でさえもありえる、と言えます。

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-02-04 21:21

引用:

k-nakさんの書き込み (2005-02-04 14:14) より:
引用:

るぱんさんの書き込み (2005-02-04 13:41) より:
既存のUMLに加筆をするのが前提であれば
既存のUMLを知らなければ問題外ではないですか？

既存のUMLについては議題の中心ではありません。
コミュニケーションのツールとして便利なので使用することはありますが、あくまでもツールです。
コミュニケーションの効率を高めるために必要に応じてカスタマイズする場合もありますが、
それはこのスレッド上での話であって、それを既存のUMLに対して改善案として提案するか
どうかは、別問題でしょう。

議論順序としては、
１．リアル⇒ドメイン
２．ドメイン⇒ソフトウェア
です。逆にすると手戻りが発生する恐れがあります。
そして、今は１に議論が絞られ始めてる、と思います。

また、１の議論を進める上では、既存のUMLで問題ないと思います。
ただ、

http://www.amazon.co.jp/exec/obidos/ASIN/4795296308/
UMLモデリングのエッセンス―標準オブジェクトモデリング言語の適用
P46-48、第４章「クラス図」の最初にある「観点」の項。

こちらにある「概念的観点」「仕様の観点」「実装の観点」のうち、
「概念的観点」での話しになると思います。（「概念的観点」は言語に一切依存しません）

ありがとうございます。
これが僕の頭の中でもたげていた問題の本質です。
UMLと一切切り離していいのであれば、全て納得です。
理解が遅いながら、お付き合いさせてしまい申し訳ありません。

その上で、やはりAサイドです。

引用:

k-nakさんの書き込み (2005-02-04 18:23) より:
私は、「リアル空間でもproperty setは存在しうる」と思ってます。
ただし、ここでいう「リアル空間」を厳密には「観測者を定めたときのリアル空間」とした場合です。

たとえば上記の「職業」プロパティについて、カード会社の顧客情報管理システムで考えて見ましょう。
私がカード会社に対して申し込みをすると、カード会社に個人情報として職業も当然記録されます。

knak.職業 = エンジニア

ところがその後の信用調査で、虚偽申請があったことが発覚し、実は無職であったとしましょう。

knak.職業 = 無職
# 注）言うまでもありませんが、あくまで例です

この場合、「リアル空間」における knak.職業は、実は何一つとして変化していないのですが、
「観測者（カード会社）にとってのリアル空間」では、knakの振る舞いなしに
「職業：エンジニア→無職」へと「認識が変化」しています。
この認識の変化に対応して property set を行うのだと思います。

他の見方をすると、たとえばシステム化以前のカード会社の業務を考えれば分かるのですが、
「顧客クラス」に相当するモノは、システム化前では「顧客票」といった書類が考えられます。
書類は記載事項の変更ができるので property set は、性別や年齢でさえもありえる、と言えます。

この文章で書いている対象がおかしいです。

コード:


┏━━━━━━━━━━━━━━━━━━┓

┃k.nak:人物                          ┃

┣━━━━━━━━━━━━━━━━━━┫

┃-職業                               ┃

┣━━━━━━━━━━━━━━━━━━┫

┃+カード会社に情報を登録():void      ┃

┃+カード会社に虚偽の情報を登録():void┃

┗━━━━━━━━━━━━━━━━━━┛



┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

┃カード会社:会社                                         ┃

┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫

┃-信用調査結果エラー[]                                   ┃

┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫

┃+信用調査():void                                        ┃

┃+顧客情報修正():void                                    ┃

┃+顧客に信用調査対象情報を入力してもらう(入力値):boolean ┃

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛



┏━━━━━━━━━━━━━━━━━━━━━━━━┓

┃顧客情報管理システム                            ┃

┣━━━━━━━━━━━━━━━━━━━━━━━━┫

┃-人物【認識】[]: DBRecord                       ┃

┣━━━━━━━━━━━━━━━━━━━━━━━━┫

┃+set人物【認識】端末入力(人物名,正しい値)：void ┃

┃+get人物【認識】(人物名)：職業                  ┃

┗━━━━━━━━━━━━━━━━━━━━━━━━┛



┏━━━━━━━━━━━━━┓

┃人物【認識】              ┃

┣━━━━━━━━━━━━━┫

┃-職業:String              ┃

┣━━━━━━━━━━━━━┫

┃+set認識（値）:void       ┃

┃+get認識():String         ┃

┗━━━━━━━━━━━━━┛

こんな感じになりませんか？
間が飛んでいる様に思います。

・・・・書くの疲れた（笑）

[編集]
お絵かきがずれたのでコードブロックにしました。
[/編集]

[ メッセージ編集済み編集者: るぱん編集日時 2005-02-04 21:24 ]

本田＠スミテム: 常連さん; 会議室デビュー日: 2004/01/22; 投稿数: 21; お住まい・勤務地: 東京

投稿日時: 2005-02-04 21:34

引用:

k-nakさんの書き込み (2005-02-04 18:23) より:
以前から「モデリングの際のちょっとした落とし穴」と思っていたことが話題に上がりましたのでレスします。

引用:

本田＠スミテムの書き込み (2005-02-04 15:28) より:

3.リアル空間では、そもそもproperty setは存在しません。
例えば、リアル空間で
　本田.職業 = 銀行員
という代入はイメージできません。
　本田.転職する(銀行員)
だと思っています。

私は、「リアル空間でもproperty setは存在しうる」と思ってます。
ただし、ここでいう「リアル空間」を厳密には「観測者を定めたときのリアル空間」とした場合です。

痛いところにツッコミが・・・。
この辺の考察は、まだ自分の中で検証できておらず、消化不良しています。
検証の助けとなる反例を頂けるのは私としては喜ばしいのですが、本論から外れますので、手短に済ませたいと思います。

引用:

たとえば上記の「職業」プロパティについて、カード会社の顧客情報管理システムで考えて見ましょう。
私がカード会社に対して申し込みをすると、カード会社に個人情報として職業も当然記録されます。

knak.職業 = エンジニア

ところがその後の信用調査で、虚偽申請があったことが発覚し、実は無職であったとしましょう。

knak.職業 = 無職
# 注）言うまでもありませんが、あくまで例です

この場合、「リアル空間」における knak.職業は、実は何一つとして変化していないのですが、
「観測者（カード会社）にとってのリアル空間」では、knakの振る舞いなしに
「職業：エンジニア→無職」へと「認識が変化」しています。
この認識の変化に対応して property set を行うのだと思います。

上記を拝読させていただき、私が感じた印象は、以下の通りです。

もし、カード会社の顧客情報管理システムがコンピューターシステムなら、
「観測者（カード会社）にとってのリアル空間」とは、実は「ソフトウェア空間」なのかなと思います。
すなわち、その空間で
　個人情報(の私).職業 = エンジニア
が成立するからといって、「リアル空間」の
　私.職業 = エンジニア
が成立するとは言えないかと思います。

引用:
他の見方をすると、たとえばシステム化以前のカード会社の業務を考えれば分かるのですが、「顧客クラス」に相当するモノは、システム化前では「顧客票」といった書類が考えられます。書類は記載事項の変更ができるので property set は、性別や年齢でさえもありえる、と言えます。

(現在)
顧客クラス.職業 = エンジニア　は、「ソフトウェア空間」

(大昔、ところによっては今でも)
顧客票.職業 = エンジニア　は、「伝票帳簿空間」

かと・・・。

#とは言え、「リアル空間」にproperty setが存在しないという確信はまだ持てないのですが・・・。

コブラ: ぬし; 会議室デビュー日: 2003/07/18; 投稿数: 1038; お住まい・勤務地: 神奈川

投稿日時: 2005-02-04 21:41

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

>これね？

引用:
見返してどうするの？それと、疑念の払拭はどうするんですか？

>これと

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

>これがどのように関係してくるの？

自分で「疑念の払拭はどうするんですか？」て尋ねた張本人が、それはないやろ (ﾌﾟ
自分のケツ拭く方法ぐらい自分で模索しましょう。

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-02-04 21:42

るぱんです。
連続投稿を失礼致します。

もっと具体的に。

～VB6.0のMSDNより引用～
→Propertyプロシージャ
[引用]
' プロパティ値のプライベート記憶域。
Private mintNumberOfTeeth As Integer

Public Property Get NumberOfTeeth() As Integer
NumberOfTeeth = mintNumberOfTeeth
End Property

Public Property Let NumberOfTeeth(ByVal NewValue _
As Integer)
' (プロパティ値を検証するコードは省略。)
mintNumberOfTeeth = NewValue
End Property
[/引用]

未記人さんの
「シンタックスシュガー」はこれで理解していただけるかな？

個人的にプロパティについて思っていたことは、
RかWかRWが明示的である・・・事を除いては
フィールドと一緒だと思います。

でも、アクセッサの中でエクセプションを投げてやれば
一緒か？

って結論ですね。

・・・で、情報に対する振る舞いの件ですが、
前の投稿で、k.nakさんが
k.nak：人物＝k.nak：人物【認識】
とされているように思います。

なにか同じ名前の違うオブジェクトについて混同されたのかな？
と思いました。

途中、間に入るオブジェクトが抜けると
このような事になりそうです。
_________________

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-02-04 21:46

引用:
コブラさんの書き込み (2005-02-04 21:41) より: 自分で「疑念の払拭はどうするんですか？」て尋ねた張本人が、それはないやろ (ﾌﾟ自分のケツ拭く方法ぐらい自分で模索しましょう。

これよんだ？

引用:
るぱんさんの書き込み (2005-02-02 10:34) より: では、zaxx_MDさんに出てきていただく以外に無いですね。今回も当然PMは飛ばしてませんし今後飛ばすつもりもありません。と言うわけで、コブラさんがPM飛ばして出てきてもらってください。

最近どうしたの？
疲れてる？大丈夫？
_________________

コブラ: ぬし; 会議室デビュー日: 2003/07/18; 投稿数: 1038; お住まい・勤務地: 神奈川

投稿日時: 2005-02-04 22:07

敢えて突っ込まんかったが、しつこいんで。
どこをどう読んだら、 zaxx_MD氏が出てくるんか... (ﾌﾟ

"「談合」の疑惑を抱いてるのは俺以外にもう一人"、の「もう一人」とは object 氏
やろうに。

はい、 1から読み直～しっ

ひょっとしてテンパってる？

_________________
日本の中心で、オフを叫ぶ（＠名古屋）。ご意見募集中！
コブラ

[ メッセージ編集済み編集者: コブラ編集日時 2005-02-04 22:10 ]

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-02-04 22:48

るぱんです。

そのとき突っ込まないのはそちらの落ち度。笑
読まないで返答を返したことは認めたわけだ？

[編集]
僕の発言に落ち度は無いみたいだよ？（笑）
[/編集]

[ メッセージ編集済み編集者: るぱん編集日時 2005-02-04 22:49 ]

«前のページへ 17|18|19|20|21|22|23|24|25|26|27 次のページへ»

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

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