- - PR -
C#とUML（クラス図）とのマッピングについて
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-12-24 20:03
Mickyさん。明るいレスをありがとうございます。 
Microsoft Visio for Enterprise Architectsではソース<-->UMLを相互に生成できるようです。どなたか使ったことのある方はいらっしゃいませんか？
やはり、そうするしかないですかね。 関係者内で一貫性があれば、特に問題ないですし。 | ||||||||
|
投稿日時: 2003-12-27 06:56
プロパティはないので、プロパティはアクセサにするしかありません。 イベントやデリゲートも、まったくありません。 | ||||||||
|
投稿日時: 2003-12-27 12:14
objectです。
以前、特集「私がJavaからC#に乗り換えた10の理由」についての中で、私は「プロパティ」に関する「Java」の欠陥を指摘しました。 あの時は、レスの内容がテーマから外れるので書きませんでしたが、「Java」に言える事は「UML」にも言えます。 つまり、「UML」と「Java」の親和性は、売りになってますが、それは全く同じ欠陥を持っているからです。 「プロパティ」は、基本要素ですから、それを他の何かで説明・表現するというのは、無理があると私は思います。 次の「UML2.0」で「プロパティ」に統一される様ですが、問題の本質は、 「プロパティ」と「フィールド」の関係 にある訳ですから、何の解決にもならないと私は思います。 「プロパティ、インデクサ、イベントをクラス図でどのように表現したら良いのか」に付いてですが、 少なくとも、「プロパティ、イベント」に関しては、今の「UML」では有効な表現方法はないと思います。 ステレオタイプで表現出来なくはないのでしょうが、何で「UML」を使用するかの原点に戻って考えると、その意味は殆ど無くなると私は考えます。 「Microsoft 開発ツール ロードマップ 2004-2005」で、MSは、次の様に書いています。 「Visual Studio "Whidbey" のデザイン ツールは、アプリケーションアーキテクチャ の中間形式として、複雑なドメイン固有のモデリング言語を使用するのではなく、 クラスからコンポーネント、Webサービス、アセンブリ、アクティビティ、および プロセスに大まかな抽象化を行い、アプリケーションモデルと元になるソースコード との間の動的な同期を維持します。」 これは、上の問題を、 「UML」のトップダウンアプローチに対して、 「.NET」はボトムアップアプローチによって、 「プロパティ、イベント」の問題を解決したい という意思表明と、受け取る事は出来ないでしょうか？ 私は、取り合えず、「Whidbey」まで待つ積もりです。 #それでも駄目なら、自分で対処するしかないのかも知れません。 [ メッセージ編集済み 編集者: object 編集日時 2003-12-27 18:09 ] | ||||||||
|
投稿日時: 2003-12-27 17:11
直接関係はありませんが。。。 Whidbeyも、2003と同じく、2003ユーザは無料なんですかねぇ。だったらうれしいですねぇ。毎年新しいツールを買い換えるなんて、お財布が許してくれませんねぇ。。。別にスレ立ててますが。 | ||||||||
|
投稿日時: 2003-12-27 21:29
objectさん、Jittaさん、ありがとうございます。
objectさんの書き込みの後半は私には難しすぎました。 Microsoftのサイトも見ましたが、Whidbeyでどう変わるのか良く分かりませんでした。すみません。 「プロパティ、インデクサ、イベントをクラス図でどのように表現したらよいか？」という疑問は、深い考えから出てきたものではありませんでした。 いわゆる「素朴な疑問」でした。 しかし皆さんのご意見を拝見したり、自分で勉強するなかで、この素朴な疑問は「なぜ、モデリングするのか？」という疑問に変わりつつあります。 私は今、クラス図を２つの用途で「試用」しています。 １つは自作クラスライブラリの設計図として、もう１つは業務に登場するエンティティの関係をモデリングするツールとして。 より役立っているのは後者のほうです。 前者の用途でもクラス間の継承、依存関係を整理している内はそれなりに有用です。しかしソースコードを忠実に表現できるモデルを作図できたとして、それが役に立つのか？よく分かりません。 悪夢を統べるものさんのご意見を、今は少し理解できたように思います。 みなさん、ありがとうございました。
....。 と、個人的にはそろそろ締めにかかっていますが、まだこの話題に書き込んで下さる方がいれば、喜んでお付き合いいたします。 :heart!: :heart!: :heart!: | ||||||||
|
投稿日時: 2003-12-28 12:27
objectです。
>Whidbeyも、2003と同じく、2003ユーザは無料なんですかねぇ。だったらうれしいですねぇ。 >毎年新しいツールを買い換えるなんて、お財布が許してくれませんねぇ。。。別にスレ立ててますが。 お財布と言えば、 「UML」ツールは、殆どの製品が無茶苦茶高いですよね。 「UML」が「インフラ」で全開発者の必須知識・ツールの如く宣伝する一方で、一製品50万円等、殆どの開発者に購入出来ない価格設定をする。 これは、一体どういう事なんでしょうか？ 「MS」に関しては、最近開発者への負担を抑える為の、実際的な努力をかなりしていると私は思います。 「VisualStudio .NET 2003 Enterprise Architect MSDN DX」でも、23万円弱で購入出来ますよね。 「Delphi 8 Architect」は一製品で3,000ドルで、33万円位ですから、もう比較にならない位に割安ですよね。 「Whidbey」は、「MSDN」でその権利を持っているユーザになら、さらなる負担なしに手に入れる事は出来るのではないでしょうか？ 「MS」には、全「VS.NET」ユーザーがインフラとして「MSのデザインツール」を何らかの形で使用出来る体制を望みたいですね！ >objectさんの書き込みの後半は私には難しすぎました。 >Microsoftのサイトも見ましたが、Whidbeyでどう変わるのか良く分かりませんでした。 そんなに難しく考えなくても良いと思いますよ？ 「Visual Studio "Whidbey" のデザイン ツールは、アプリケーションアーキテクチャ の中間形式として、複雑なドメイン固有のモデリング言語を使用するのではなく、 クラスからコンポーネント、Webサービス、アセンブリ、アクティビティ、および プロセスに大まかな抽象化を行い、アプリケーションモデルと元になるソースコード との間の動的な同期を維持します。」 に関してだけ、私なりの解釈の要約を書きます。 1) 「Whidbey」では、「ドメイン固有のモデリング言語」(恐らくUMLの事)を使用しない。 2) モデルとソースコードの同期を維持する。 3) 1)2)より、モデルは「UML」以外の何らかの表現手段、つまりモデリング表現手段(言語)を使って表現される。 4) そのモデリング表現手段は、中間形式である。 5) 2)より、ソースコードの基本要素、「プロパティ」「メソッド」「イベント」は、モデル空間で表現される。 「MS」は「複雑なドメイン固有のモデリング言語」と記述しています。 要するに、ここの議論と同じで、「UML」は使えないから使わないという事だと思います。 #でも、ここで間違われると困るので書いておきますが、 #「UML」は使えない #とは #「UML」を否定してるのではなく、 #ただ単に今の「UML」では「.NET」上のモデルを表現出来ないと言っているに過ぎない #という事です。 #「.NET」上での新しいモデル表現は、最終的には可能な限り「UML」をベースに纏められると思います。 それから、モニンチさんにお聞きします。 「オブジェクト指向設計」は一度綺麗に忘れて，一から設計し直す とありますが、 一から設計し直しても、 結局それは「オブジェクト指向設計」ではないでしょうか？ もしそうで無いとすると、それは何なんでしょう？ | ||||||||
|
投稿日時: 2003-12-30 17:52
objectさん。
休みで実家に帰った影響で、返信が遅くなりました。すみません。 丁寧に解説して頂きありがとうございます。 やっと理解できたような気がします。
「オブジェクト指向設計」とは何か？ 私にはそういった難しいことは良く分からないんですが、未記入さんの書き込みをこう解釈しました。（もちろん勝手な解釈ですが。） UMLではソースコードを、そっくりそのまま表現することはできない。 だから、プロパティをどう表現しようか？などということに悩むより、 もっと基本的で、本質的な設計ができるよう、勉強したほうが良いですよ。 私のモットーは「手っ取り早く、楽して儲ける」なので、基礎からジックリ学んだことがありません。 が、休みの間に結城浩さん著の「Java言語で学ぶ デザインパターン入門」（ソフトバンクパブリッシング株式会社）を読もうと思っています。（友人が薦めてくれました。） ＃（訂正）やっと理解できました。→やっと理解できたと思います。 ＃（訂正）やっと理解できたと思います。→やっと理解できたような気がします。 [ メッセージ編集済み 編集者: モニンチ 編集日時 2003-12-30 17:54 ] [ メッセージ編集済み 編集者: モニンチ 編集日時 2003-12-30 17:56 ] | ||||||||
|
投稿日時: 2003-12-30 22:31
モニンチさん、objectです。
>休みで実家に帰った影響で、返信が遅くなりました。すみません。 そんな事は、全く気にしなくても大丈夫です！
>UMLではソースコードを、そっくりそのまま表現することはできない。 >だから、プロパティをどう表現しようか？などということに悩むより、 >もっと基本的で、本質的な設計ができるよう、勉強したほうが良いですよ。 モニンチさん、おっしゃりたい事は、分かります。 でも、「オブジェクト指向分析・設計」が今の「UML」に結実するだけでも、本当に大変だったんですよ！ だから、「基本的で、本質的」なオブジェクト指向分析・設計は、そんなに容易な事ではないと思います。 「UML」に関しては、「プロセス」抜きでは理解し難い部分があると私は思います。 「UML」に対するプロセスの一番の候補は、矢張り「統一プロセス(UP)」なんでしょうね。 そう言えば今、復刊ドットコムで、絶版になっていた「オブジェクト指向ソフトウェア工学OOSE」(Ivar Jacobson)の予約受付を1/7迄やっています。 8000円と少し高めですが、記念碑的書籍ですから、読んでみるのも良いかもしれませんよ。 >休みの間に結城浩さん著の「Java言語で学ぶ デザインパターン入門」（ソフトバンクパブリッシング株式会社） >を読もうと思っています。（友人が薦めてくれました。） デザインパターンは、「UML」等の表現手段無しには、全体の構造・関連を鳥瞰するのは難しいと思いますよ。 それから、「GoF」のデザインパターンは、もちろん大切なのですが、 「ブッシュマン」の「ソフトウエアアーキテクチャ」(近代科学社￥4600)がかなり勉強になると思います。 「アーキテクチャ」と「パターン体系」を扱っていますから、「デザインパターン」の位置付けができますし、 「GoF」と異なる「デザインパターン」を扱っていますから、私はお勧めだと思います。 [ メッセージ編集済み 編集者: object 編集日時 2003-12-30 23:29 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。