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

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

投稿者

投稿内容

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

投稿日時: 2005-01-28 12:27

引用:

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

不適切な表現が含まれていたため一旦削除します。

ごめんなさい。削除前のをすでにみてしまってます^^;

じゃあ、忘れてください。プロとして好ましい書き方ではなかったので。

引用:
zaxx_MDさん、ご指摘、ありがとうございました。一応、Javaでも仕事してる身ですので、今後設計の際に意識してみるようにします^^;

　いえ、役に立てば幸いです。
人に言っておいてなんですが、私も設計段階でそこまで考えられないことが多いです。
本来なら気づいた段階で作業スケジュールを修正してリファクタリングする
べきなのでしょうが、なかなか許されないものでして・・・

横道にそれますが、(jakarta.common.)BeanUtilはリフレクトパッケージを
利用しているので、多用は禁物です。特にデプロイ領域のHDDが遅い場合に、
原因不明のパフォーマンス劣化を起こすことがあるので、注意してください。
strutsもリフレクトつかってますが、ちゃんとキャッシングしてるので、
それほどパフォーマンス劣化にはなりません。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 12:28 ]

すみませんが、スレ主(>>1)さんの返答を意訳してくださる方、
いらっしゃいませんか？
私への返答が含まれているのか理解に苦しみます。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 12:31 ]

未記人: ベテラン; 会議室デビュー日: 2004/08/21; 投稿数: 70

投稿日時: 2005-01-28 12:49

引用:
objectさんの書き込み (2005-01-28 11:55) より: しかし、「Java」ユーザーの反発は根深いものがある様です。今は、「Insider.NET会議室」で「スレ」をたてなかった事を少し後悔しています。

.NETのプロパティに対する反発ではなく、
あなたの議論(になってないですが)の仕方に対する反発だと言う事に気付きましょう。
そもそもあなたの主張を理解できる人が殆どいないのですから、主張の内容に反発する事などできません。
議論のスタイルを変えない限り、河岸を変えても同じ事。

ところで、状態量の種類がここでの議論にどう関係するのか全然わかりません。

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

投稿日時: 2005-01-28 13:12

るぱんです。

単に可視性の話で終わりで良いんですか？
他にも何か語るべきことが残ってるんじゃないんですか？

プロパティとfieldの違いだけで終わっちゃうんですね？
ん～。なんだ、そんなことか・・・。
もったいないなぁ・・・。

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

投稿日時: 2005-01-28 13:13

申し訳ありませんが時間がないので一言だけレスです。
（他にもありますが、帰宅してからにします）

＞objectさん
移行される際には、
「議論参加資格：構造主義、代数学を身につけておられる方」
と最初に書かれることをおすすめします。
シャノンさんへのレスはそういうことですよね？

tak3: ベテラン; 会議室デビュー日: 2004/04/15; 投稿数: 80; お住まい・勤務地: 菜の花・銀杏

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

私の見解は、やはりUMLで困っていないです。
# つまり、プロパティの概念を現状必要としない。

自分はOO言語っていうとJavaしか使えないのですが・・・
「振舞的情報」と、そうでない情報よりも、
「情報を加工/設定するための振舞」と「サービスを提供する振舞」と区別して考えてます。
# 「アクセッサメソッド」と「いわゆるメソッド」

で、C#におけるプロパティは、アクセッサのシンタックスシュガーであると考えます。

つまり・・・
「C#のプロパティ・メソッド」は
「Javaのメソッド・メソッド」と思ってます。

# ドメイン空間での情報がpublicであるっていうのが無い考えです。
# 情報自体は必ずなんらかのアクセッサを経由して取得すると考えます。
# Field = 情報と思ってませんが、Property = 情報とも考えません。

で、いわゆるC#に限らないプロパティ論ですが、アクセッサでいいかなぁと思ってます。
なんでもget、setで済ませちゃってます。

Listの例がでてましたが・・・（以下Javaの話です）
size と size( ) と getSize( )で、実際どれだけ困るの？
っていうと命名に余計な手間かけなくてすむぐらいかな・・・
# size( )とgetSize( )は等価と考えてます -> どちらもsizeへのアクセッサ
# size でのアクセスは「振舞を持てない」というので大いに困るというのは、わかります

まぁこの辺をどう考えるか統一するためにプロパティが必要ってことなんでしょうか。

引用:

ここでの議論と結果は、結局
「Javaを含むあらゆる言語」にプラスになる
と考えたからでした。

しかし、「Java」ユーザーの反発は根深いものがある様です。
今は、
「Insider.NET会議室」で「スレ」をたてなかった事
を少し後悔しています。

もし、みなさんのご了解を頂ければ、「Insider.NET会議室」に移行する事も今は考えています。
この事に関して、意見を頂ければ幸いです。

移行していいんじゃないですか。

どこでやっても最終的には後発の言語がイイトコどりするようになってるんで
それがUMLまで波及することもあるかもしれません。

らぶま: 常連さん; 会議室デビュー日: 2004/10/21; 投稿数: 32

投稿日時: 2005-01-28 13:19

再び通りがかりです。

独り言に返答ありがとうございます。>objectさん

ただ、申し訳ありませんが、

objectさん>>「代数構造」＝「情報・振舞」、「プロパティ・メソッド」に於ける「和・積」構造です。

の部分がよく分かりません。
「情報・振舞」に対して代数系を定義するなら、
「和」と「積」を明確に定義する必要があると思います。
既に記載済みかもしれませんが、改めて明記してもらえませんか？
後、上記演算の定義の根拠も示してもらえるとありがたいです(検証ができるから)。

また、objectさんの仰る「準同型」とは、
「現実世界」→「ドメイン空間」→「ソフトウェア空間」
は必要だが、逆写像
「現実世界」←「ドメイン空間」←「ソフトウェア空間」
はなくてよい、という理解でよいですか？

独り言:
なんか、Javaと.NETの話になってるみたいですね。
私はてっきり、
(分析?)モデリング(言語・方法論)は実装言語に依存しないはずではないの？
という話題かと思っていたのだが・・根本の認識間違い??

[ メッセージ編集済み編集者: らぶま編集日時 2005-01-28 13:29 ]

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

投稿日時: 2005-01-28 13:45

可視性だけでいいんじゃないですか？

fieldのアクセサを公開しない場合を例として出すと、

　ミドルウェアやドライバ・ラッパーを作成して、
他の技術者にインタフェースの情報をJavaDocで提供するときに、
下層側に依存したfieldを上層から直接操作されると、
意図しない動作をする可能性があるとき。
protectedやprivateを利用して要素とgetA/setAを定義したことがあります。

　また、下層へのアクセスで利用する
クラスで一意の非公開の固定値を定義する場合は
staticもしくはfinal staticで定義したことがあります。

　これらはpropertyではなくfieldとして定義したい場合の
解決策になっていませんか？

　さらに、メソッドにオプション指定項目を引数として公開している場合に、
受け付けるパラメータを公開要素としてfinal static public (int)で定義して、
case文で処理を書き分けたりもしました。
　これはpropertyとして定義したい場合の解決策になってませんか？

そういう論点と違うのでしょうか？

ここまで書く必要もないかもしれないし、
上記の例が正しいことかどうかも確定できないですけど。

Javaに限定した議題なのかどうかも理解に苦しむし、
モデリングを主眼としたプロセスの問題としても理解に苦しむ次第で。

　業務改善作業の延長としてのソフトウェア開発プロジェクトの場合、
リアルとドメインとプログラムで、それぞれの空間で都合のいいように
構成を変えることが極当たり前に行われていることを考えると、
プロパティとかフィールドなんて上から下まで一緒のことの方が
ケースとしてはるかに少ないのは定義方法が違うから当然だと思うのですが。

例えるなら金額のフィールド/プロパティは本来ならCurrencyで
定義しなければいけないのですが、
long とか int とか doubleで定義されることがほとんどなわけです。

　プログラム言語としても、Javaだけで実装されることは珍しく、
SQLやJavaScriptを併用するプロジェクトが多数を占める現状で、
要素の定義の仕方に問題があるというのはナンセンスだと思いました。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 13:49 ]
[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 13:50 ]
[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 13:57 ]

と、ここまで書いたあとInsider.NETのスレッドをチラッと見たら、
namespace宣言の話題がありました。

Javaだと文法としてnamespace宣言できないという意図で
このスレッドを立てたのだとしたら、
できません。ごめんなさい。

　DBの世界でいうところのアトリビュート・リストが
中規模以上のプロジェクトで必須なことは知ってますが、
たしかにjavaでnamespace宣言に近いことをやろうとすると、
とてもとても手間がかかります。

　手法としてはjava1.4まではnamespaceスーパークラスをルートとする、
共通型定義の塊を定義することになるわけです。
まだjava1.5を触ったことがないので、なんともいえませんが、
1.5でも文法的に名前空間の定義はできないでしょう。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 14:10 ]
[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 14:12 ]

と思ったら、ごめんなさい。
static import という名前空間の定義がjava 1.5から使えるようになりました。

定義の仕方はheaderファイルぽいところがいやらしいですが。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-28 14:31 ]

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

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

スレを読ませていただいて｢このことを言いたいのでは？」と感じたことを書きます。
間違えていたらご指摘くださいませ。

////////////////////////////////////////////////////////////
プロパティ
オブジェクトが保持している変数に対して値の設定および取得が
行えるもの。
オブジェクト.プロパティ=XXXで値の代入を行う。
オブジェクト.プロパティで値の取得を行う。
メソッド(Setter/Getter限定で考えてください)
オブジェクトが保持している変数に対して値の設定もしくは取得が
行えるもの。
(設定用のメソッドと取得用のメソッドを実装する)
オブジェクト.メソッド(XXX)で値の代入を行う。
オブジェクト.メソッド()で値の取得を行う。

UMLのクラス図にはフィールドとメソッドはあるが、プロパティに該当する項目がない。
なので、現状のクラス図でプロパティを表現しようとすると、
1)プロパティを値を取得するメソッドと値の設定をするメソッドとして表現する
2)プロパティをフィールドとして表現する
の2パターンが考えられる。
(コメントとか注釈で｢これはプロパティです｣って書くことは除いて)

1)のパターンでプロパティを表現してしまうと
オブジェクトの使用側がプロパティをメソッドと勘違いして
コーディングする可能性がある。
2)のパターンで書くと
クラスの実装者がプロパティをフィールドと勘違いして
フィールドとして実装してしまう可能性がある。

設計者と実装者で認識の相違が出るのは、よいとはいえない。
よってプロパティはプロパティとしての表現方法を作る事が必要ではないか？
////////////////////////////////////////////////////////////

私はオブジェクト指向はJavaしか実装経験はなく、.NETに関しては
今回のスレを読んで勉強した程度でしかないのですが、
プロパティで実装することで=で代入を意識するのはいいなぁと思います。

プロパティの代入でもSetterでも変数に値の代入をするだけの処理を行っているのなら
フィールドの可視性をpublicとかにしてしまえばいいって考えもありますが、
入力チェックや計算・処理を行うのであれば可視性だけの問題では済まなくなると思います。

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

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

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