＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-27 18:21
不適切な表現が含まれていたため一旦削除します。[ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:09 ] | ||||||||
|
投稿日時: 2005-01-27 20:41
いくつかの仮定が必要ですが、モデリング→Javaの実装において
FieldsとPropertiesについての実装方法についておかしいと指摘されている件は 「JavaBeans」の作法がオブジェクトマッピングする精神衛生上好ましくない。 という問題だとして、 １．J2EEを利用する開発者の中にはJavaBeanとして実装することが全てのケースにおいて正しいと盲信する人がいることは確かに問題です。 ２．業務分析を徹底せずに紙を元にした画面とまったく同じオブジェクトを設計の元にしたままだったり、(DOA/DODの)RDBの設計が設計の出発点とするプロジェクトだと、入力項目＝JavaBeanとかレコード＝JavaBeanのまま引き回したりして、レコード＝オブジェクトになっていたりするのも問題です。 ３．意味としてのモデリングを無視して粒度の大きなオブジェクトのままデザインパターンを考えなしに適用してしまうのも問題です。 JavaBeansは一番有名なjavaのカプセル化手法ですが、 オブジェクトを全てJavaBeanで実装しろというわけではありません。 設計者＝モデラーの視点から見て、JavaBeansでしか実装してくれない場合、 どういうアクセスパターンか限定せずに実装しなくてはならない状況で、 とりあえず変更に強い実装として選択されることが多いわけです。 そういう場合はシステム全体（のモデリング）を教育することが不足してたり、 実装担当者のjavaのスキルレベルが低かったりします。 でも、それらはプログラマ個人の問題だったり、 プロジェクト固有の問題だったりして、 javaの本質の問題ではないのです。 javaの本質的な問題はプロパティの前置詞が初心者には判りにくく、 SUNのjava認定試験で問題として良くでてくるほど、 javaの根幹をなす要素なことです。 ※プロパティの前置詞とは、プロパティ宣言の前に記述される final/static/public/private/指定なし などを指しています。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:43 ] [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:46 ] 結局投稿せずにはいられない私を藁ってクダサイ（ワラ [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:47 ] [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:54 ] [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:55 ] [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:56 ] [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 20:57 ] つまり、中級以上のJavaプログラマにとって、 多くの場合、問題にならない問題を論じているわけで、 非常に疲労感を感じてしまいました。 ですから「郷に入っては郷に従え」ということです。 もし、.NETとJAVAが会話するプロジェクトで設計する場合、 できるかぎりインタフェースを最適化して会話数を減らすことを オススメします。ダブルスタンダードだったり、 意味の無い定義が無駄に設定されてしまうことでしょう。 ダイナミックにお互いを補完しあうようなデザインをすると、 疲れるだけで実りは小さいものです。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2005-01-27 21:03 ] | ||||||||
|
投稿日時: 2005-01-28 00:42
今までずっとjavaの関数の中で、List#size等の値取得系なのに「get」がついてないものに
疑問を抱いていたのですが、このスレッドを読んでいて答えが出ました。 それはsizeはプロパティだからだと。 つまり、"getSize"にしてしまうと「Listはsizeを返します」になってしまうので、 "size"にして「Listはsizeという属性を持っています」と定義したかったのではと。 上記の様に考えると明示的にプロパティだと定義出来る何かがUMLに欲しいですね。 
[修正] 日本語修正 [ メッセージ編集済み 編集者: ぽん 編集日時 2005-01-28 00:51 ] | ||||||||
|
投稿日時: 2005-01-28 01:02
ごめんなさい。削除前のをすでにみてしまってます^^; ただ、削除された書き込み内容ですが的確な指摘が含まれていたと思います。 削除された書き込みなのでどうこう言うのは、あまりよくはないかな、 とも思うのですが、そのまま削除されるのはもったいない、と感じましたので zaxx_MDさんの指摘内容を自分なりに解釈、自分なりの言葉で書いてみます。 私のはじめの投稿にあるプロパティの可視性に関する図や文章ですが、 なぜこのようなことを考えたかというと、最近、JavaのほうでBeanUtils関連のクラス を発見したときに「あ、Javaにも、こういったのあるんだな」と思ったことがあります。 DotNETのほうではSystem.ComponentModel名前空間あたりに似たようなのがあるんですよね。 で、比較した時に思ったのが「DotNETではTypeDescriptor.GetPropertiesで プロパティのみを取得することになるが、言語要素としてのプロパティがないJavaでは、 実装にのみ現れるgetter/setterもプロパティとして拾ってしまうのでは？」 というものでした。 その考えが、あのようなプロパティの可視性に関する文章につながっていった わけなのですが、そもそもこの考えには見落としがありました。 実装のみに現れるgetter/setterなら、それらをprivateなりパッケージ可視性なりに すれば問題なく必要なプロパティのみを取得できるんですよね。 言われてみれば、なんともまぁ、初歩的な見落としだなぁ、とは思うのですが、 そのことに気づかせてくれるzaxx_MDさんからの指摘があるまでは getter/setter はpublicで固定、と何の疑いもなく思ってました。 なんでそんな思い込みを…？と考えたときに、zaxx_MDさんの再投稿内容の
こういったことにつながるんでしょうね。 とりあえず私の最初の投稿の可視性に関する部分は、上記のような 初歩的な見落としによる考察不足があることを強調しておきます。 （さらに考察を進めることで、再び元の考えに戻る可能性もありますが、 私の最初の投稿にその考察がされていないことは事実ですので） zaxx_MDさん、ご指摘、ありがとうございました。 一応、Javaでも仕事してる身ですので、今後設計の際に意識してみるようにします^^; …で、ちょっと本題からずれてしまうのですが、私の最初の投稿、 やっぱり色々とまずかったかなぁ…、と反省しています。 最初の投稿の冒頭に書いた「推敲不足」には、このスレッドの現状に対する考慮不足も含みます。 なので、問題ない形に文章を仕上げるまで投稿しない、という選択肢との間で悩んだんですよね。 ただ…、自分の考えを他の人に聞いてもらいたい、他の人からの意見を聞いてみたい、 って欲求が勝ってしまいました^^; 実際、投稿したことでzaxx_MDさんからご指摘いただけて、自分の考えの穴に 気づくことができ、そのことについては「やっぱり投稿して良かったな」と 思うのですが、自分の配慮不足でzaxx_MDさんに無駄な疲労感を負わせて しまったようでほんと申し訳ないです。 まぁ、あんな投稿（あちこち断定的な文章）を書いておいてなんですが、私は ”私の考えは絶対正しい”という考えは持たないように意識しているつもりです。 （自信はありましたけどね^^; ただ、そういう時に限ってお約束通り穴あるし…） | ||||||||
|
投稿日時: 2005-01-28 09:09
これについては、JavaBeansにおけるプロパティの定義から見たときは、 むしろgetSizeでないとまずいのではないかな、とも思います。 Listを設計したときはJavaBeansの定義がまだ存在せず、 それゆえsizeがUMLでの属性（プロパティ？）であることを強調するために、 動詞をつけなかったのでないかな、と。 （動詞をつけないことで振る舞いでないことを表現） ただ、それではUMLの属性に対するread/writeを考えたときに、 Read: int propertyA(); Write: void propertyA(int a); となってしまい、メソッド名だけではread/writeが表現されてないので JavaBeansにおいてはset/getをつけることにしたのではないかな、と思っています。 | ||||||||
|
投稿日時: 2005-01-28 11:31
objectです。
>maysさん 困っていなくて、改善の必要性を感じていないのなら、そのままで良いと思いますよ？ 今の気持ちを大切にするのが一番だと思います。 >未記人さん 相変わらず、自分はレス無しで、私にはレスを求めるんですね。 >シャノンさん そういう内容の議論している訳ですから、ご容赦下さい。 >棒助さん 「皮膚感覚」で理解出来ないのは、棒助さんの問題だと思いますよ？ 「代数構造」というのは、あらゆる所に影響します。 実数の計算が簡単に出来るのは、「結合法則・交換法則」等が保証されているからです。 「プロパティ」の場合は、プログラムの表現が自然になると思います。 >ALL 例えば、「量」を扱う場合、「加法的な量」と「加法的で無い量」が出て来ます。 この「加法的で無い量」は、「加法的な量」を扱う中で、「必ず必要になって来る量」です。 そして、 「加法的で無い量」＝「機能的な量(内包量・示強量)」 です。 具体的には、「温度」なんかがあります。 | ||||||||
|
投稿日時: 2005-01-28 11:41
objectです。
>k-nakさん k-nakさんが何を仰りたいのか理解出来ません。 また、k-nakさんのレス(投稿日時: 2005-01-27 02:11)の表現は、 実際の 「C#等のプロパティ・メソッド」 と 「Javaのフィールド・メソッド」 を表現し、私が行った説明を少し付加しているだけです。 一番重要な部分(レス：投稿日時: 2005-01-24 12:54) --------------- 「プロパティ・メソッド」≠「フィールド・ファンクション」 の意味は、 「フィールド」⊂「プロパティ」 「メソッド」⊂「ファンクション」 という意味です。 つまり、今迄の関係を拡張している訳です。 --------------- 或いは、「積構造」に関しては、何も表現出来ていませんよ？ #私は、k-nakさんが表現された内容を、特には問題視しなかっただけです。 #内容が、網羅されていて完全であるとは言わなかったと思いますよ？ ハッキリ言って、「構造」が無いと思います。 #私は構造を問題にしている訳です。 | ||||||||
|
投稿日時: 2005-01-28 11:55
objectです。
>ALL この「スレ」に於ける、私の目的は 出来ればある程度権威のある組織で 「プロパティに白黒をつける」 という事です。 #「モデル」をベースとして 私の「プロパティ」に対する解釈は、「プロパティ」の重要性を少しでも分かって頂く為に、参考につけたものです。 従って、これは未だその正当性が決まったものでもありませんし、必要以上に拘っても意味が無いと思います。 #正式な解釈・定義をして貰うというのが、この「スレ」の目的です。 私としては、どうにかして 「プロパティ」の概念を明確化され、より使い易いツールが生まれる という流れにしたいと思っています。 #そうでないと、この事による被害は、拡大する一方だと私は思っています。 私が「IT Architect 会議室」でこの「スレ」をたてたのは、 ここでの議論と結果は、結局 「Javaを含むあらゆる言語」にプラスになる と考えたからでした。 しかし、「Java」ユーザーの反発は根深いものがある様です。 今は、 「Insider.NET会議室」で「スレ」をたてなかった事 を少し後悔しています。 もし、みなさんのご了解を頂ければ、「Insider.NET会議室」に移行する事も今は考えています。 この事に関して、意見を頂ければ幸いです。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.