2

私はSparxEA（現在のバージョン）を使用して、クラス図（重要な場合はC＃）の簡単な小さなテストソリューションをリバースエンジニアリングしています。クラスは2つだけです。Test1およびTest2。Test1にはプロパティがあります。

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

そのプロパティに基づいて、EAは2つのクラスが関連していると推測し、それに応じて図を更新することを期待しますが、そうではありません。2つのクラスを取得し、手動でリンクする必要があります。

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

4

1 に答える 1

4

まず、質問コメントでの議論は根本的な問題を浮き彫りにしていると思います。UMLのどの関係が実装言語Xのどの構成に対応するかについてのコンセンサスはありません。

言い換えれば、最も一般的な実装言語用の標準化されたUMLプロファイルはありません。（Javaには非常に古いものがありますが、廃止されています。）これはUMLの大きな失敗のひとつであり、特定のツールの問題ではないと思います。

質問に答えるために：いいえ、この場合、EAは依存関係や使用法を推測しません。しかし、ここでの問題はさらに深刻です。EAはテンプレートタイプを正しく解決しません。

例を拡張して、次の4つのケースを検討してください。

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

EAは、属性ではなく操作として表すプロパティを認識します。これらのコネクタは作成されません。一方、プロパティ以外のものは、属性と有向関連の両方によってモデルで表されます。このように使用される属性と有向アソシエーションは、UMLでは意味的に同等ですが、操作には同じことが当てはまりません。

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

test2ListAttrまた、有向アソシエーションの多重度は0..*であることに注意してください。これは、EAがこの属性が実際にはリストであると正しく推測したためです。この推論は、[ツール]-[オプション]-[C＃]-[追加のコレクションクラス]で制御できます。

ここでそのオプションを削除List<#TYPE#>;してから、モデルにテンプレートクラスListを作成し、インポートをやり直すと（この場合、最初にモデルをクリアすることをお勧めします）、EAはの表現を変更しtest2ListAttrます。への0..*向けの関連付けを作成する代わりに、実際のパラメーターとして指定して、クラスにTest2バインドするテンプレートを作成します。ListTest2

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

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

関連する注意点として、EAに操作の戻り値とパラメーターの種類の依存関係を作成させることができます（ただし、テンプレートの種類の使用については作成できません）。これは、[ツール]-[オプション]-[ソースコードエンジニアリング]で設定されます。

于 2012-04-15T11:28:18.467 に答える