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

«前のページへ 3|4|5|6|7|8|9|10|11|12|13 次のページへ»

投稿者

投稿内容

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2005-01-28 14:22

引用:
夏椰さんの書き込み (2005-01-28 14:03) より: 入力チェックや計算・処理を行うのであれば可視性だけの問題では済まなくなると思います。

　入力チェックも計算・処理もメソッドだから、fieldとして
要素をprivate宣言すればよいし、UML中にもprivate宣言できますよ？

　UML上に定義されたメソッドがアクセサーかどうかは
Aというfieldが定義されている場合に、公開されたアクセサーつまり
getA()/setA()が定義されていたら、それはpropertyである
というJavaBeansの決まりのようなものがあるので、
熟練した設計者とプログラマであれば混同することはありえません。

今川美保(夏椰): ぬし; 会議室デビュー日: 2004/06/10; 投稿数: 363; お住まい・勤務地: 神奈川県茅ヶ崎市

投稿日時: 2005-01-28 14:58

引用:

zaxx_MDさんの書き込み (2005-01-28 14:22) より:
　入力チェックも計算・処理もメソッドだから、fieldとして
要素をprivate宣言すればよいし、UML中にもprivate宣言できますよ？

　UML上に定義されたメソッドがアクセサーかどうかは
Aというfieldが定義されている場合に、公開されたアクセサーつまり
getA()/setA()が定義されていたら、それはpropertyである
というJavaBeansの決まりのようなものがあるので、
熟練した設計者とプログラマであれば混同することはありえません。

Javaでは、要素の可視性をprivateにして隠し、
要素に対してアクセサーメソッドを定義することで
要素の値を書き換える・取得するという動作を実現することが多いと思いますから
現在のUMLの表記で足りていると思っています。

ただ、プロパティのように
見た目はオブジェクトの要素を参照しているように見えて、
実はアクセサーだって言うものの表記が今のUMLでは出来ないことが問題として
捕らえられているのではないか？と思ったんです。

ですから、今は可視性の問題ではなく、
プロパティが
･使う側から見たコード上の見た目がオブジェクトの変数にアクセスしている
･実装自体はメソッドのようになっている
という2面をもっている
のに、その状態をUMLで表現できないことだと思います。

burton999: ぬし; 会議室デビュー日: 2003/10/06; 投稿数: 898; お住まい・勤務地: 東京

投稿日時: 2005-01-28 16:50

難しいことはよくわかりませんが、

引用:
ですから、今は可視性の問題ではなく、プロパティが･使う側から見たコード上の見た目がオブジェクトの変数にアクセスしている･実装自体はメソッドのようになっているという2面をもっているのに、その状態をUMLで表現できないことだと思います。

これが今回の問題であればステレオタイプで表現すればいいのではないでしょうか？
私はEnterprise Architectというツールを使用していますが(http://www.sparxsystems.jp/)
.NETのソースをリバースエンジニアリングすると

<<Property>>Size

のようにメソッドの欄に表示されます。
ですので上記の件では困ったことはありません。

今川美保(夏椰): ぬし; 会議室デビュー日: 2004/06/10; 投稿数: 363; お住まい・勤務地: 神奈川県茅ヶ崎市

投稿日時: 2005-01-28 17:16

引用:

burton999さんの書き込み (2005-01-28 16:50) より:

これが今回の問題であればステレオタイプで表現すればいいのではないでしょうか？
私はEnterprise Architectというツールを使用していますが(http://www.sparxsystems.jp/)
.NETのソースをリバースエンジニアリングすると
<<Property>>Size

のようにメソッドの欄に表示されます。
ですので上記の件では困ったことはありません。

このツールではプロパティをメソッドと同じように記述して
<<property get>><<property let>>をつけることで
これはプロパティですよって表現しているんですよね。
(教えてくださったページの参考図http://www.sparxsystems.jp/images/classdiagram.png
でそうおもいました)

これがUMLでのプロパティ表現方法として
定義され明示されている文章を見つけられなかったのですが…。
(探し方が下手なのかしら？)

もしそのようなページがあれば、ぜひ教えてください。
自分の勉強不足なんで。

(以下追加)
自分のスタンス的には、プロパティがプロパティだよって判れば
何でもいいかなぁって思ってしまったりするんですが、
誰もがこれがプロパティだ!って認識できる書き方があればベストかな～
と思っています。

[ メッセージ編集済み編集者: 夏椰編集日時 2005-01-28 17:42 ]

burton999: ぬし; 会議室デビュー日: 2003/10/06; 投稿数: 898; お住まい・勤務地: 東京

投稿日時: 2005-01-28 17:25

もちろん正式にUMLで定義されていないです。
そもそも、UMLで定義されてないものとかを扱うためにステレオタイプって使用するのではないでしょうか？（間違ってたらゴメンナサイ）

http://wisdom.sakura.ne.jp/solution/uml/class/uml1_3.html

永井和彦: ぬし; 会議室デビュー日: 2002/07/03; 投稿数: 276; お住まい・勤務地: 東京都

投稿日時: 2005-01-28 17:34

引用:
.NETのソースをリバースエンジニアリングすると <<Property>>Size のようにメソッドの欄に表示されます。ですので上記の件では困ったことはありません。

とりあえず、ただの表記法の観点からですが、同じ例外表現(ここでは<<Property>>)があまりにも頻繁に繰り返し現れるならば、それは何がしかの方法で正規に表現出来るようにしてしまった方がいいと思います。
と言うか、これを逆にして突き進むと「<<Field>><<Method>>と付いてるからあんな区切り線とか無くても全然問題無いです」……になるような気がするのです。

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

投稿日時: 2005-01-28 17:37

らぶまさんのレスの写像って言葉でようやっとピンときたかも…。
積構造って、積集合の積ですか？

となると、objectさんの言葉を言い換えると、

DOMAIN = REAL ∩ SOFTWARE

このことをベースに考えると今までが、

{fields, methods} ⊂ (SOFTWARE - REAL)

で、今までの関係を拡張したものを定義することで、

{properties, functions} ⊂ (SOFTWARE)

となる、……ということでよろしいでしょうか？

ほんとただ言い換えただけですが、私の理解があってるかどうかを
確認する、という意味で確認お願いします。
（上の式、記号の意味を調べながら書かなければいけなかったくらい
の私ですので、数式の記法にミスがありましたらご容赦ください）

ただ、あってたとして……それの意味するとこを考えるのはこれからです（汗

[一部削除して追記]
再度、見直してて思ったのですが、objectさんのらぶまさんへのレスを
自分はきちんと読んでませんね。
それを読んだ後だと上の式は修正しないといけないでしょうね、たぶん。
まずはそこから始めます。

[ メッセージ編集済み編集者: k-nak 編集日時 2005-01-28 18:13 ]

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2005-01-28 18:00

まず恥を覚悟で素人的な質問をしますが、そもそも振舞と情報の客観的な区分け手段は存在するのでしょうか？
存在しないとするならば「振舞をプロパティ」で「情報をメソッド」で反転した実装が可能だと想像しました。

己の無能さを話に持出すのは間違いだと指摘されるかもしれませんが。しかし厳密な境界線、決定的な違いがなければグレーゾーンは存在する事となり、ちょっとした要因で、振舞（メソッド）や情報（プロパティ）に変化する訳ですよね。

夏椰さんの意見を伺うとプロパティでは代入表記が出来る様ですが。もし、これが後に情報では無く振舞であったと考えを改めても、プログラミング上の利用側において既に情報だと限定した扱いの文法が存在しえる為に概念の変更がし辛い問題が起きるのでは無いでしょうか？

一時的な開発行為だけを考えるならば問題では無いのかもしれませんが、やはり運用の事も考えると概念の変化（人の成長）を阻害する要因を排除するメリットを考えると、メソッドだけで振舞や情報を実装する言語仕様も無視出来ない考えだと思います。

正直な所、自信が無いので御意見お願い致します。 m(_ _)m

«前のページへ 3|4|5|6|7|8|9|10|11|12|13 次のページへ»

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

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