ゲストの「ゲスト」さんからの投稿です。
---

前回はお世話になりました。
C#に限った事ではなさそうですが、別件でクラスの関連で不具合らしきものがありましたのでご連絡します。



図のようにクラス図でクラス間に関連線を引いた後、その関連線を消去しても、C#コードを生成すると関連情報がコード上に残っています。上図でも別名ツリーに関連の痕跡が残っているので分かると思います。

生成コードは以下のようになります。


usingの最後にクラス名が付く不具合は以前にご連絡した通りです。

改善要望として
(1)Class1はテンプレートを使用しているので、関連の型名にテンプレートの情報を入れられると良いです。具体的には、Class2.csの6行めが、
private Class1<string> class1;
などと出力できると良いですね。
(2)多重度が1..*だと配列が生成されますが、これを別途List<>などのコレクションクラスが指定できると良いですね。

評価バージョンは前回と同様Pro5.4.1です。

以上、宜しくご検討お願い致します。

引き続きのご評価、どうもありがとうございます。

引用：

こちらは不具合ではありません。JUDEには次のような２種類の削除方法があり、
目的に応じて使い分けることができます。
・図から削除
・モデルから削除

「図から削除」を実行した場合、その図のみから図要素が削除されます。
「モデルから削除」を実行した場合、モデルおよび関連する全ての図要素が削除されます。
貼りつけられた画像を拝見しますと、「図から削除」を選択されたのではないでしょうか。

参照：JUDEリファレンスマニュアル
4. 基本概念 - 4.2.2「図から削除」と「モデルから削除」
（リファレンスマニュアルは、上部メインメニュー [ヘルプ]-[リファレンスマニュアル] より開くことができます）

引用：

確かにこうした操作ができると便利そうですね。
ただ、残念ながら現時点では C#に限らず Java等でも対応はできておりません。

ご意見、どうもありがとうございました。今後もよろしくお願い致します。

ご存知かもしれませんが、ちょっと補足させていただきます。

引用：

これらは、関連をつかわずに、属性を使った場合には、実現可能です。
今のJUDEで関連を使う場合は、テンプレートバインディングを利用して作成されたバウンドクラスに関連を引く必要があります。

ゲストの「ゲスト」さんからの投稿です。
---

引用：
関連などもこういう仕様だったのですね。大変失礼しました。

引用：
同時に評価している某コード生成に強いツールですと、(1)はできないようですが、(2)はできますね。

方向性が違うツールだからと言われれば仕方がないですが、今後に期待しております。

以上、宜しくお願い致します。

ゲストの「ゲスト」さんからの投稿です。
---

引用：
関連を属性でというのはコード生成の観点からは理解できますが、UMLの意味が違ってきてしまうので、適用は難しいです。関連が正確にコード生成できなければ、手書きするしかないですね。

アドバイスありがとうございました。

ゲストの「M.A」さんからの投稿です。
---

こんにちは．

先日似たような内容がありましたが，違う立場からのコメントです．

私は，複数の案件に関わるコンサルタントです．最近の案件ではUMLに関する案件も多く，ツールも対象になります．

そのような立場ですから，JUDEと，話題になっている某ツールの両方を長く利用しています．ただ，ややJUDEよりの立場です．方針に共感します．



私はJUDEの最大の特徴はマインドマップから始まる一連の分析手法と考えており，この手法をデモして今まで顧客にJUDEが導入されなかった例はありません．

逆に，ソースコード生成を重視する案件では，現在のJUDEの機能では全く役に立ちません．某ツールの機能は圧倒的であり，比較すれば優劣は明らかです．

操作性は，現状は五分五分と考えます．JUDEは最近は操作性の強化がなくMDAばかりなので，以前の長所も失われつつあります．

仮にJUDEがMDAを重視して機能強化するとしても，2年は遅れている状況です．世界はもっと先に進んでいますので，いまさらMDAツールが1つ増えても，勝つのは難しいと考えます．

しかし，この上流に関する一連の機能は類の無いものであり，ここを伸ばすことで他に無い製品になると，私の経験から申し上げます．

JUDEは既存ツールと同じ存在を目指しているのか，あるいは既に持っている特徴を伸ばして，独自の存在になるのか，気になります．
折角のフォーラムなので，開発者の意見を伺いたいところです．既知の機能を単に実装して満足なのか．未知，独自の機能を開発して世界に勝負を挑む気概はあるのか．

>私はJUDEの最大の特徴はマインドマップから始まる一連の分析手法と考えており，この手法をデモして今まで顧客にJUDEが導入されなかった例はありません．

すごいです！＆ありがとうございます！

はい、私もいろんな方にいろんなデモをしますが、この部分はJUDEが誇れる部分ですし、JUDEの後でいろんなツールがMindMapをUMLに取り入れています。最近も新しくマインドマップを入れたUMLツールがでましたね。ですので、ここは、JUDEの方向性としてがんばって行きたいと思っています。

MDAというか、ソース生成/リバースは現在APIが充実してきているのとあまりにも要望が多いので入れています。ここは、よろこんでくれる方が多いので、やりがいがある部分でもあります。

>JUDEは既存ツールと同じ存在を目指しているのか，あるいは既に持っている特徴を伸ばして，独自の存在になるのか，気になります．

これは、私からの意見だと投資対効果、という話になってしまい、バランスと判断です。でも、開発者（エンジニア）がどう考えるか、という話はとても重要で、「こんな風にしたい」というエンジニアの想いが一番ストレートに出たものがいいツールに結果的になって、売れていく、というのも真実だからです。

開発者からも意見を聞いてみることにしましょう。

こんにちは。コメント大変ありがとうございます。
JUDEのことをよく考えていただけていることをうれしく思います。

まず、JUDEがMDAを重視するように方針転換したわけではない、ということをお伝えしておきます。
最近の言語対応の拡張は、JUDEの要望として多くいただいていたものに対応したものです。

M.Aさんがおっしゃるように、すでに存在しているツールと全く同じものを作っても、使っていただけないと思っています。
そういう意味で、私は、ユーザの方に支持していただける特徴をぜひつくっていきたいと思っています。

ただ、多くの方に支持されるような、新しい開発手法を作り出したり、全く新しい機能を見出すことは、とても難しいことだとも思っています。
そんな中、やっぱり、ユーザの皆さんからの声（要望や困っていること）をたくさん聞いて、考えていくことが大切だと思っています。
私の感覚としては、今も一生懸命考えている最中、なんです。

回答になっていないかもしれませんが、今後もぜひいろんな声をお寄せいただければ幸いです。

激励のお言葉ありがとうございます。
Kota＠JUDE開発部です。
JUDEは、コンセプトである使いやすいツール、マシンの方向ではなく、現場のコミュニケーションを促進する、
より上流へ等のコンセプトにユーザーとの対話を重視し、開発・改良を行ってまいりました。

しかしながら、最近の新機能の傾向としまして短期的に見ると
コンセプトとずれているじゃないか、JUDEはMDAの方向へ進んでるじゃないかと思われるかもしれません。

リリースノートを見てもらえればわかりますが、ここ数年でビジネスよりのER図、
組み込みでよく使用されるC++等が追加されています。
ビジネスよりのER図は対応していない時期には、対応してほしいという要望も絶えることはなかったですし、
以前に業界内の組み込み開発のボリューム増加にともないC#,C++,Cへの要望が高い傾向にございました。
ここは長年JUDEが苦手とするところで、手をつけず優先度が低い状況にありましたが、
多数の要望に押される形でC以外は対応してまいりました。

バージョンUP前には製品会議というものがあり、
弊社平鍋、営業、セールス、サポート、開発も同席して
次の新機能どうするみたいなことを議題でミーティングします。
以下の観点で全員で共有した上で、次の新機能を全員の同意のもと決定しています。
・開発部がこうしたい。
・ユーザーからこんな要望があるがどうするか？


以下は、開発部の私からみたJUDEの強み・弱みです。
[JUDEの強み]
・比較的マニュアルレスで操作できる直感的操作感
・マインドマップ経由の分析・設計

[JUDEの弱み]
・リバース・フォワード系
・MDA

これについては
育児するときでも、どっちを重視するかは個人によっても違うと思いますが、
基本的に私は長期的には"強み"を伸ばしていきたいという思いでいます。
個人的ですが、Appleのスティーブ・ジョブズ氏を尊敬しております。
iMacやiPhoneなど革新的な製品を生み出すカリスマです。
二番煎じになる製品より、唯一無二である製品でお客を喜ばせる。
チェンジビジョンの開発部のでそのような製品をだせるかは、
そもそも恐れ多く、超難題ですが、ぜひ一歩でも二歩でも近づけるように精進していきます。

しかしながら、ツールを安定的に長期間ユーザーに提供するには、
投資対効果も重要なファクターだと思います。
ソフトウェア開発でも現実的には例外なく付きまとう問題です。

既存ユーザーを満足させ、さらに新規ユーザーを獲得していくのには
想像力が必要です。
この機能追加しても、XXX(ビジネス系、組み込み系、WEB系、上流工程etc)
の人うれしくないんだよね等の議論はよく開発部で議論になります。
広い視野と先入観なしの視点を磨いていきたいです。

JUDEで要望を随時受け付けていますが、
やはりすべての人を満足させるのは至難の業であることも十重承知です。

最近の傾向でいうと言語対応でいささか下流で対組み込み対応が強かったので、
既存の非組み込み系の人には、その機能選定が残念だったかもしれないことは
今後の機能選定で改善していきたいと思います。
基本的にはよりたくさんのユーザーによりたくさんの有用な機能を
ユーザーがぐっと来る優先度で反映していきたいと思います。

なので強み・弱みどっち伸ばしていくかへ質問の回答も
そのときの状況によって柔軟に決定を下し、製品への反映をしていきたいと思います。
あと、「M.A」さんのようなJUDEに期待していただいているユーザーも大切にしていきたいと思いますので、
今後もよろしくお願いいたします。

コメントありがとうございます。
JUDEに対する熱い思いが伝わってきて嬉しくなりました。

# 以下、私見ではございますが

　　　　　上流　　　　　下流(MDA)
JUDE　　　←−−−−−−⇒(最近の傾向)
某ツール　　　　−−−−−−−→

言語対応の機能は下流方向への拡張ではございますが、
MDAを目指すというよりは、通常の用途(曖昧な表現で申し訳ございません)に
おいて使用する可能性が高いところを強化したという意識でいます。

上流指向がJUDEの持ち味ではございますが、他のツールも含めて
扱える問題領域においても、(改善の余地はございますが)使いやすさを
武器に潜在ユーザーに対してアピールすることを期待しています。
もちろん、JUDEをお使いいただくことで、そこから上流にも興味を
持っていただければとも思っています。

なお、実現可能性はまだわかりませんが、現在、上流方向の拡張も
検討しているところですので、下流のみの拡張が延々と続くようなこと
にはならないと思っていますし、やはり上流こそが強みになるとの想いも
チームで共有できていると私は思っています。

今後もJUDEをよろしくお願いいたします。