3.2β版のご試用とフィードバックをありがとうございます。下記の手順でSQLを、物理名、論理名のどちらで作成するかを指定することができます。1.[ツール]-[ER図]-[SQLエクスポート]で[SQLエクスポート]ダイアログを開きます。2.[オプション]ボタンを押下します。3.[出力するモデルタイプ]で希望するモデルタイプを選択して[了解]ボタンを押下します。3.2β版では[論理モデル]がデフォルトになっているようです。今月末リリース予定の3.2正式版にて[物理モデル]をデフォルトにいたします。ご連絡ありがとうございました。ベータ版へのコメントゲストの「kterao」さんからの投稿です。---ERモデルに論理モデルと物理モデルがありますが、どう使い分けるのかよく分かりません。一般的に考えれば、物理モデルはテーブル仕様に近いものだろうと思いますが、JudeでSQL生成すると物理名でなく論理名が現われます。物理名でSQL生成した方がよいのではないかと思いますが、いかがでしょうか。ベータ版へのコメントゲストの「たかはし」さんからの投稿です。---2.xでは、Genericsを使ったソースのリバースエンジニアリングが出来なかったので、3.0になって出来るようになると期待していたのですが...非常に残念です。型情報をどうするのか、難しい判断が必要だとは思いますが、検討していただけるとありがたいです。ベータ版へのコメントeijiさん、ありがとうございます。ご指摘どおり、すごく変です。内部的には、修正済みです。ロール名もちょっとおかしいところがあります。ベータ版へのコメントゲストの「eiji」さんからの投稿です。0..*[ClassB]になっちゃいました。1[ClassB]の形だったんですけど。langパッケージ本日内部的に修正いたしました。ベータ版へのコメント浜田さんすいません。Community版の不具合が含まれています。Community版では、今までどおりの見た目になるように修正されます。おっしゃるように、ユースケース図で誘導可能性は、ほとんど意味をもたないように思います。確かに誘導可能性を明示的に使いたい場合は、それほど多くないと思います。)がデフォルトだったことと、Javaコード出力時に参照していることもあり、このようにしています。できればもう少し状況を改善したいと考えています。ベータ版へのコメントゲストの「浜田」さんからの投稿です。ユースケース図で誘導可能性が意味を持つのでしょうか。クラス図であれば、理解しますが。それと、デフォルトの扱いかと思います。誘導可能性を明示的に使うのが一般か(多いか)というところかと思います。あるほうが使いやすいように思います。「関連するものとして、システムプロパティに、「UML2.0の仕様で関連を表記する」というオプションがあります。」は、communityには無いようですね。langパッケージゲストの「ron」さんからの投稿です。ベータ版へのコメント浜田さんコメントありがとうございます。これ実は、UML2.0の誘導可能性の表記に変換しているためなのです。UML1.xで曖昧だった誘導可能性を、UML2.0ではより明確に表現できるようになっています。今のところ仕様にしたいと考えていましたが、改善案ありますでしょうか?関連するものとして、システムプロパティに、「UML2.0の仕様で関連を表記する」というオプションがあります。