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

«前のページへ 11|12|13|14|15|16|17|18|19|20|21 次のページへ»

投稿者

投稿内容

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

投稿日時: 2005-02-02 12:26

本田＠スミテムです。
すいません。
肝心の質問に返答していませんでした。

引用:
るぱんさんの書き込み (2005-02-02 09:34) より: 下のコードはだめですか？

既に暗に答えているとは思いますが、オブジェクトのインターフェースに「振舞」のみを認識されているのでしたら、OKだと思います。

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

投稿日時: 2005-02-02 12:49

るぱんさんへの返答を考えている間に、おそろしく整理されたレスが……
しかも私の最初の投稿の図を活用していただいてとても嬉しいです

個人的にはあの投稿以降、あの図を「UMLとC#からインスピを得ている」
ということで一人で勝手に「UML#」と呼んでます（笑
# ただ、まだここでは話題に出してない要素もありますけどね＾＾；

あと、私の最初の投稿、ある方からのPMで気がついたのですが、
UMLの操作と属性、上下逆にしてますね。。。（UMLと書いてないとはいえ）

普段UMLを使ってないことがバレバレです

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

投稿日時: 2005-02-02 13:24

>あなたが感じた溝とはなんですか？
>説明していただけませんか？

既に、自分の発言と私の発言を故意にか、無意識にか取り換えようとされておられる。
自分は、過去に「あんたは、都合の悪い事には沈黙」「同じ行動に対して温度差をつける」
と書き込んだ事はあっても、「溝」云々はあんたが一方的にそう書いただけで、私には
何の事やら・・・＞るぱん

そうやって意図的な曲解・こじつけやっとると UML における議論(議論なんかどうかは
ともかく)での信憑性も疑わしいものになりかねまへんで。

仮に、ここでの「定義」が「溝＝温度差」っちゅぅなら、過去の
「それはもう、決まった事だから」っちゅぅスレッド検索して、オノレの発言読み
返して見る事ですな。

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

投稿日時: 2005-02-02 13:46

本田＠スミテムです。
こんにちは。

引用:

k-nakさんの書き込み (2005-02-02 12:49) より:
るぱんさんへの返答を考えている間に、おそろしく整理されたレスが……
しかも私の最初の投稿の図を活用していただいてとても嬉しいです

個人的にはあの投稿以降、あの図を「UMLとC#からインスピを得ている」
ということで一人で勝手に「UML#」と呼んでます（笑
# ただ、まだここでは話題に出してない要素もありますけどね＾＾；

「UML#」、とてもいいです。
今すぐ、いろいろ試してみたい気持ちです。

ところで、前の私の投稿で、k-nak様風でなかった部分がありましたので、修正させてください。
#表記上の問題で、主旨に影響はないと思います。

Bタイプ、ドメイン空間2について、

コード:


┌──────────┐

│ Window             │

├────┬─────┤

│ Left   │ m_nLeft  │

│ Right  │ m_nWidth │

├────┼─────┤

│ Show   │ SetLeft  │

│        │ GetRight │

│        │ DoShow   │

└────┴─────┘

ではなく、

コード:


┌────────────────┐

│ Window                         │

├────┬─────┬─────┤

│ Left   │ SetLeft  │ m_nLeft  │

│ Right  │ GetRight │ m_nWidth │

├────┤ DoShow   │          │

│ Show   │          │          │

└────┴─────┴─────┘

でした。

k-nak様には、お名前をお借りしてまで利用させていただきましたのに、大変失礼しました。

m_nRight -> m_nWidthに修正

[ メッセージ編集済み編集者: 本田＠スミテム編集日時 2005-02-02 13:54 ]

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

投稿日時: 2005-02-02 14:23

こんにちわ、オブジェクト指向B型のk-nakです。
（↑この表現が気に入りました（笑））

なるほど・・・私の最初の投稿を「よりprivateなものほど右」という風にとらえられたわけですね。
（確かにそう書きましたしね）

ただ、今から改めて考えてみると、ドメイン空間で「メソッドとプロパティ」の対が
できていることと、ソフトウェア空間で「ファンクションとフィールド」の対が
できていることを明示したい、という観点から本田＠スミテムさんの修正前の図のままで
なんら問題ないと思います。（objectさんが言われてた「関係の拡張」と対応する意味でも）

加えて言えば、プロパティやメソッドから見たら、
フィールドもファンクションもpublicである、とも言えますので。
（でないと単純プロパティ＝フィールドと直結するプロパティ、の実装で
　フィールドが使えなくなります）

# ところで上記単純プロパティで思い出しましたが
# C#でそれこそシンタックスシュガーとして欲しい記法
# property public Type PropertyName;
# フィールドいちいち別に確保するのが面倒なときありますからね＾＾；

コモンセンス: 会議室デビュー日: 2005/01/05; 投稿数: 15

投稿日時: 2005-02-02 15:17

コモンセンスです。

このスレッドを興味深く読ませていただいています。
おそまきながら少し参戦？

スレ主のobjectさんの問題意識に(マクロには)共感します
(抽象的問題なのであまり共感されない人も多いようですが)。

たとえば、
>現在の「モデリング言語」は、そのベースが、どれも「結局」は
>「ソフトウエア空間」内に留まっている
Yesと思います。
>MDA、Executable UMLその他を含めて。
>「モデリング言語(手法)」は本当に今のスタンスとその延長で良いのでしょうか？
それではまだまだだと思います。

ただobjectさんの具体的問題点指摘と解決提案は、間違いではないが
パワーが足りないなという印象です。「精密な計算をしているが
それでなにか新たなことが見えたとは思えないな(それくらいなら
わかっていますよ)」という感じです。

たとえば、
>「ソフトウエア空間の代数構造に欠陥がある」
これはどういうことをおっしゃっているのか
もう少し説明されたほうがよいと思います。
そして直感的には「代数構造」のような数学的道具立て
くらいでモデリング問題の核心部にせまれるとは思えません。

それから、Hsさんの「オブジェクト指向＝抽象データ型」論
(そう理解しましたが)も方向?が逆だと思います。

「モデリング論は単なる数学的道具なんかでは片づかない。
向かうべきはその逆方向ではないですか」と言いたくなりました。

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

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

本田＠スミテムです。

引用:
k-nakさんの書き込み (2005-02-02 14:23) より: こんにちわ、オブジェクト指向B型のk-nakです。（↑この表現が気に入りました（笑））

このスレでは私もオブジェクト指向B型です。
#メッセージのことを考えてしまうと突然変異してX型になりそうです。

引用:

なるほど・・・私の最初の投稿を「よりprivateなものほど右」という風にとらえられたわけですね。
（確かにそう書きましたしね）

ただ、今から改めて考えてみると、ドメイン空間で「メソッドとプロパティ」の対が
できていることと、ソフトウェア空間で「ファンクションとフィールド」の対が
できていることを明示したい、という観点から本田＠スミテムさんの修正前の図のままで
なんら問題ないと思います。（objectさんが言われてた「関係の拡張」と対応する意味でも）

加えて言えば、プロパティやメソッドから見たら、
フィールドもファンクションもpublicである、とも言えますので。

確かにそのとおりですね。
修正後の図はなんとなく可視性にばかり気をとられていて、恐らくobject様がおっしゃる「和・積」構造を記法として満足に表現できてないかと思います。

ただ、修正前の図にしても、
　プロパティ = f(フィールド、ファンクション)
　メソッド = g(フィールド、ファンクション)
が正しく伝わるかどうか微妙です。
　プロパティ = f(フィールド)
　メソッド = g(ファンクション)
と誤解されないか心配です。

#左右を隔てる縦線の代わりに斜線をクロスさせたりしてみましょうか。

また、まだ考えがまとまらないのですが、私自身はもしかすると、
　プロパティ = f(フィールド、ファンクション)
　メソッド = g(フィールド、ファンクション)
ではなく、
　プロパティ = ファンクション(フィールド)
　メソッド = ファンクション(フィールド)
と考えているようです。

単純プロパティ＝フィールドと直結するプロパティは実装上便利ですが、ドメイン空間2には持ち込みたくない気がしています。

# とくに自分で示したコードがそうだったからかも知りません。
# 言語に思考を縛られてるかな・・・。

# 頭の中で、メッセージ-インターフェース-「プロパティ、メソッド」
# -ファンクション-フィールド-オブジェクト-クラス
# といったキーワードがめぐっています。
# 考えがまとまった頃に別スレッドを立てるかもしれません。

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 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-02-02 22:44 ]

«前のページへ 11|12|13|14|15|16|17|18|19|20|21 次のページへ»

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

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