リバースエンジニアリングと推論関係のSparx EA？

Question

私はSparx EA（現バージョン）を使用して、簡単な小さなテストソリューションをクラス図にリバースエンジニアリングします（問題があればC＃）。ほんの2つのクラスがあります。 Test1とTest2。 Test1にはプロパティがあります。

public List<Test2> test2list { get; set; } 

そのプロパティに基づいて、私は、EAは、二つのクラスが関連していることを推測し、それに応じてダイアグラムを更新するために期待されるが、それは..私はちょうど2つのクラスを取得し、それらを手動でリンクする必要はありません。..

EAに関係を認識させる方法はありますか？

Answer 1

まず第一に、私は、問題の議論がハイライトに根本的な問題をコメントと思わない：どのUMLにおける関係は、別の言い方をすれば実装言語Xに

を構築するためにどの対応するようコンセンサスがない、何があります最も一般的な実装言語の標準化されたUMLプロファイル（Javaには非常に古いものがありますが、それは廃止されています。）このツールはUMLの大きな失敗の1つであり、特定のツールの問題ではありません。

質問に答えてください：いいえ、EAはこの場合依存関係や用途を推測しません。しかし、ここでの問題は深刻です：EAはテンプレートタイプを正しく解決しません。あなたの例を拡張し

、これら4例を考えてみます - ない属性

public List<Test2> test2ListProp { get; set; } 
public List<Test2> test2ListAttr; 
public Test2 test2SingleProp { get; set; } 
public Test2 test2SingleAttr; 

EAは、それが事業として表しプロパティを認識します。これらのコネクタは作成されません。一方、非プロパティのものは、属性と指向的な関連付けの両方によってモデルに表されます。この方法で使用されるアトリビュートとディクショナリアソシエーションは、UMLでは意味的に同等ですが、操作については同じ意味を持ちません。

モデルに入り、Test2の名前を変更すると、属性とプロパティの両方で非リストタイプの名前が正しく更新されますが、他のタイプはList<Test2>タイプを保持していることがわかります。だから、これが壊れるところです。 List<Test2>タイプは文字列であり、適切なモデル参照ではありません。

また、ダイレクトアソシエートtest2ListAttrは多重度0 .. *を持つことにも注意してください。これは、EAがこの属性が実際にリストであると正しく推測したためです。この推論はTools - Options - C＃ - Additional Collection Classesで制御できます。あなたは今行くとそのオプションからList<#TYPE#>;を削除した場合

、そしてEAはtest2ListAttrのその表現を変更します（この場合は最初のモデルをクリアするには、おそらく良いアイデア）インポートをモデルに、テンプレートクラスListを作成して、やり直し。 0 .. *の指定された関連付けをTest2に作成する代わりに、Listクラスにバインドするテンプレートを作成し、Test2を実際のパラメータとして指定します。

Test2の名前を変更すると、バインディングが更新されます（図をリロードする必要があります）。つまり、これは正しい表現であり、コードを生成する場合このモデルから、それは正しいでしょう。実際には、このように設定されたオプションとListクラスが事前に作成されているため、上記の4つのケースのうち3つの動作が正しいです。

ただし、テンプレートクラスであるプロパティのプロパティの問題は解決しません。EAはそれらを操作として表しているため、それらのための直接的な関連付けを描画することはできません。そのため、テンプレートバインディングを描画することもありません。もし私があなたであれば、これをバグとして報告しなければなりません。

関連するノートでは、オペレーションリターンとパラメータタイプ（ただし、テンプレートタイプの使用ではない）の依存関係をEAに作成させることができます。これはツール - オプション - ソースコードエンジニアリングで設定されます。