MLのほうで以前から「関連クラスが…」と言っていた者です。
今度のJUDE 3(Community)にそれがついて喜んだ…のですが、見たところ、私が期待した機能とはだいぶ違うものが実装されてた (それしか実装されてなかった)ので残念に思っています。
ひとことで言ってしまえば、Rose風の関連クラス変更機能が(も)欲しい、ということです。
以下、説明します。

(以下のAsciiArt(?)では、全角バックスラッシュを、「左のモノと上のモノをつなぐ線」のつもりで使います。具体的にいえば関連クラスと関連の間の点線のつもりです。)

JUDEで

クラス0------------クラス1

という関連の線に対して「関連クラスに変換」をすると

クラス0------------クラス1
関連クラス0／

というような関連クラスが新規に作成され、逆にこの関連クラス1に対して「関連に変換」をすると、関連クラス0が削除されちゃいますよね。

削除されるってことは、UNDO以外の手段では回復不能だということです。

これは私が夢見てた挙動とはだいぶ違います。 (そういう機能も有ってもいいですが、それだけだと困ります。)

だって、消えちゃうってことは、「いろんな関連クラスを着脱してみる」という揺さぶり((C)児玉様)が、できなくなっちゃいますから。

私としては「消す」機能じゃなく「はずす」そして「とりあえずそのへんに置いておく」機能が(も)欲しかったのです。

クラス0------------クラス1
関連クラス0／

の"／"の部分を触って「関連クラスでなくする」などというコマンドを実行すると、

クラス0------------クラス1

関連クラス0

という風につながりが切れてしまうような機能を、です。
そして逆に、

クラス0------------クラス1

関連クラス0

の関連(?)クラス0に対して、関連の線に「ぶら下がりなさい」と命じれば、

クラス0------------クラス1
関連クラス0／

になってくれる、というような機能をです。

(Roseだと関連クラスを関連にDragDropすれば出来上がる…んじゃなかったかな…)

＝＝＝＝＝＝＝＝＝＝＝

あと現状の、関連クラスに対して行える「クラスに変換」というコマンドですが。

この挙動は「そういうモデル(の変更の仕方)の解釈も有る」という程度のものだと思います。
一種のベストプラクティス。

それはそれで、それを一発で変換してくれる機能がついているのは有意義だと思うのですが、
一方で、上記のような「見たまんまやんか！」という感じの変更を行える機能も、
無いと駄目だ…と私は思っています。

＝＝＝＝＝＝＝＝＝＝＝

あと、それこそ関連クラス周りで、なんかバグりました。JUDE Community 3.0.1。Javaは1.4.2_05。以下の手順で出来ちゃうみたいです。

０：サラで起動してプロジェクトの新規作成する。デフォルトで存在するクラス図を開く。
１：クラスを2つ作る。デフォだと「クラス0」「クラス1」になる。
２：両者の間に関連クラスを作る。デフォだと「関連クラス0」になる。
３：１の両者の間に再度、関連(関連クラスじゃなく素の関連)を作る。
４：３の関連を「関連クラスに変換」する。
４に対するJUDEの反応：あのー。＜＜一見何も起きないんですけど…＞＞
５：ファイルを保存する
５に対するJUDEの反応：保存できず、エラーダイアログが出る。ログファイルには
JP.co.esm.caddies.golf.model.BadTransactionException: Operation should be out of transaction.Call EntityStore#commitTransaction() first.
とかってExceptionが出る。

ところでこれって、ちょうど、
「関連を同一のクラス間に複数引くのは禁止！」という話と
「関連クラスも複数引くのは禁止！」っていう話
(私はそのUMLの仕様に賛同しませんが…)に
絡む実装の部分ですよね。

JUDEは以前から関連(クラス)を複数引けるようになっていたので、
これを作成だけじゃなく変更も可能に機能強化したとき、
どう折り合いを付けるのかな？と楽しみにしていたのですが、
残念ながら今のところエラーになっちゃうという
(そういう意味では最悪の)
実装状況というか設計状況であるようです。

なお私は、クラスじゃなく素の関連ならともかく、
関連クラスにした場合は、
同じ2つのクラス間に複数の関連クラス(や、それどころかインスタンス)を
作れてもいいじゃん、と思っている人です。

(その発想に基づいて実装設計を行っていれば、上記のエラーは起きなかったんじゃないでしょうか？
関連クラスが複数ある状態を最初から想定していなかった…んじゃないか？と邪推しています。)

素の関連なら
「区別不能→複数引くの禁止」
という理屈はわかりますが、
せっかく関連クラス(オブジェクト)にしたのだから、
オブジェクトの「識別可能」という性質を活かせば、
「区別可能→複数引くの許可」
という理屈になる(してもいい)ハズだと思うので…

いや、(とりあえずJUDEに対して)何を言いたいかといいますと、
上記の「バグ」に対して、どういう修正をするご予定かを聞きたいのです。
「関連クラスを複数引くの禁止」
という仕様に変更するのでしょうか？
もしそうなら、今までそういう抜け穴を使っていた(^^;私としては非常に困るので、
乗り換えますから。
乗り換えの必要が有るかどうかを出来れば早めに教えて頂けると
(対策をとる都合上)嬉しいですので、出来れば早めにお願いします。

----------------
A.nakamuraです。

A.nakamuraさん
開発者のmurataです。
誠にご丁寧かつ詳細なレポートとご提案を下さりありがとうございます。
関連クラスの使い勝手に関するご提案については、今後の開発の参考にさせていただきます。

また、レポートしていただいたExceptionですが、手順4の前に、関連のベースを「関連クラス0」にしてから手順4を行う事で再現いたしました。

ご迷惑をおかけしますが、できるだけ早期に対応させていただきますので、よろしくお願いします。

うーん。どんなふうに受け止めて頂けたかは、とりあえず伺えない文面ですね。企業だから仕方ないと思っておいたほうが宜しいでしょうか？
(あ。発言者のかたお一人についてそう思ってるというわけではありません(のでどうか気に病まないで＞murataさん)。私が感じてるこの傾向は、JUDEのかたがた全般について私が感じていることです。)

バグそのものは(少なくとも今は)別に「迷惑」とは思っていません。無料で使わせて頂いてるということもあって、多少あるのは覚悟の上で使っていますから。
それよりどちらかといえば、自分の「夢(^^;」をJUDEに託すことが出来るかどうかのほうが重要だと思っています。

ーーー

というわけで、応答っぽい文章は書きようがないので、代わりにこちらの要望について1つ補足しておきますと…

今のカタチの変換も不可逆な変換だ、という辺りが気になっています。

こちらは情報量が「増える」変換なので、自分でがちゃがちゃ頑張れば(記憶を頼らずに)元に戻すことは出来ますが、それでも手数が相当かかるので、ふつう行いたい作業ではなさそうです。

もともとあの変換は原理的に不可逆(いったん変換したあと、逆変換を妨げてしまう編集を行えば、戻しようがなくなる。例えば多重度を弄っちゃうとか)なので、逆変換を実装してないってのは、それはそれで正しい姿勢かとも思います。

ただ、あれを「関連クラスに似たもの」だと「見なす」という設計上の判断(^^;をなさった以上、「無理でも」元に戻すことが出来ないと、ツールとして辻褄がついてないことになるんじゃないかと…。

個人的には、
Class0(x)------(y)Class1
AscClass0---／
を
Class0(1)----(y)AscClass0(x)------(1)Class1
に読みかえるってのは、
かなりの思考のジャンプを要するアクロバティックな話だと思っています。

つまり
「似てない」
と思っています。

そんな「高度な」変換をサポートしてハマる(具体的には逆変換の道を自ら難しくしてしまう)よりは、それより前に「平易な」変換をサポートしてくれる姿勢のほうが、嬉しかったかもなあと思っています。

----------------
A.nakamuraです。

naka_akiさんへ

回答がものすごく遅れてしまって申し訳ありません。
この件についてどう対応したらよいか開発チームで考え中です。

ですので、もうしばらく回答をお待ちください。

naka_akiさん補足コメントありがとうございます。
jude-usersメーリングリストでの会話も通して、おっしゃっていることを理解しているつもりです。確かにそういう方針（「平易な」変換をサポートする）も、とてもよい方針だと思っています。

ちょっと説明しづらいですが、今回は「関連クラスが一つあったときに、それは関連とクラスそれぞれのインスタンスがくっついているのではなくて、関連クラスのインスタンス一つが存在する」という方針のもと、現在の変換機能を提供することを決めました。ただ、この方針でもnaka_akiさんのおっしゃっている「平易な」変換の挙動を実現してもよかったかもしれません。

皆さんも、「平易な」変換の要望強いでしょうか？

ML でも言った気がしますが、

interface IAssocClass extends IAssoc, IClass {}

class AssocClassImpl implements IAssocClass{
IAssoc assoc;
IClass klass;
}

という設計にすれば良かったんじゃないかと思っています。
interfaceは多重継承、実装は集約。

またもちろん、そうでなくても、内部的には頑張ってコンバートすれば済むことですし。どうせコンバートはトランザクションの中で行われる(処理中はユーザ操作もファイル保存も介入しませんよね)わけですから、やろうと思えばできますよね。

>皆さんも、「平易な」変換の要望強いでしょうか？

この設問は…どうなんでしょう？(^^;

悪い言い方をすると、世間でここ数年、偉い先生がたや声の大きいかたがたが寄ってたかって「関連クラスなんか使えない！」と言い放ってくださったおかげで、関連クラスユーザ狩りが済んじゃってるんじゃないかと思います。なので設問に回答しえる母集団が少ないような予感がします。もちろん予感は裏切られることを期待してはいますが。

まあ私も、ほんとにUMLの仕様を額面どおりに守るなら「使えない」と思うことも有ります。むしろ微妙にユルい実装(設計)になってるJUDEはかえって有りがたいですね(^^;。
額面どおりのUMLは現代上流工程における行番号ベーシックなんじゃないか？という気がしてます。JUDEのように微妙にユルくつきあうのが落としどころとして秀逸だと思っています。

近況：
Railsの「has_many :through」で出来る中間テーブルが「関連クラス」なのかどうか気になっています(^^;

----------------
A.nakamuraです。