資料 ID: GI88-4111-00
© Copyright International Business Machines Corporation 2007. All rights reserved.
この資料の最新バージョンは、
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html で 入手できます。IBM® Rational® Modeling Extension for Microsoft® .NET は、Rational UML モデリング製品用の C# および CTS モデリング拡張です。この設計および開発ツールのファミリーは、オープン・ソースの Eclipse フレームワークを基に構築されています。Modeling Extenstion for Microsoft .NET ソフトウェアのプラグインを使用して、ソフトウェア・アーキテクトおよびモデル駆動型開発の担当者は、C# アプリケーションおよび CTS 型を視覚化し、統一モデリング言語 (UML 2) を使用した優れたアーキテクチャーを持つ C# コードを作成できます。
Rational Modeling Extension for Microsoft .NET を使用して、次のことができます。
- Microsoft Visual Studio 2005 から .Net ソリューションをインポートして、Eclipse プロジェクト内にあるソリューションのミラー・イメージを作成する。
- C# アプリケーションを視覚化する。
- 参照ダイアグラムを使用した Architectural Discovery および依存関係分析。
- クラス図を使用したアプリケーション構造の文書化。
- シーケンス図を使用した、as-implemented および what-if クラス相互作用の文書化。
- 「混合モデリング」理論の操作の一環として、UML モデルのダイアグラム内に .NET 型を描写。
- UML モデルの C# コードへの変換。
- C# コード変更の UML モデルへの変換。
インストール要件の最新詳細情報については、次の Web サイトにあるこの README ファイルの更新バージョンを参照してください。 http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.
インストールのランチパッドにある製品のインストール・ガイド、および製品 CD の文書ディレクトリーのインストール・ガイドを参照することもできます。
Rational Modeling Extension for Microsoft .NET には、IBM Installation Manager v1.0.0.2 以降、および IBM Rational Software Architect、IBM Rational Software Modeler、または IBM Rational Systems Developer のバージョン 7.0.0.1 が必要です。 これらの必須バージョンがインストールされていないと、ソフトウェアのインストールは続行されません。
IBM Rational Modeling Extension for Microsoft .NET バージョン 7.0 のインストールについては、次の Web サイトに掲載されているインストール説明を参照してください http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/install_instruction/install.html。
また、製品のインストール・ガイドは、インストール・ランチパッドからも、1 枚目の製品 CD の「文書 (documents)」ディレクトリー内でも表示できます。
モデリング拡張ソフトウェアは、IBM Rational Software Architect v7.0.0.1、IBM Rational Software Modeler v7.0.0.1、または IBM Rational Systems Developer v7.0.0.1 の GA ビルドにインストールすることができます。 次の手順は、インストール・プロセスの概要です。より詳細な説明は、「IBM Rational Modeling Extension for Microsoft .NET Install Guide」を参照してください。
インストールする手順は、次のとおりです。
- 上記の規定どおりに Rational UML モデリング製品がインストールされていることを確認します。
- IBM Installation Manager で、モデリング拡張をインストールするホスト製品を選択します。
モデリング拡張はホスト製品とシェルを共用し、Eclipse の同じインスタンスを使用します。- Installation Manager のウィザードに従って、モデリング拡張のインストールを完了します。
これらのリリース・ノートには、製品資料が最終的に完成するまで利用不能であった情報が含まれています。C# プロファイルを使用して .NET アプリケーションをモデリングする場合は、次のベスト・プラクティスおよびガイドラインを使用してください。
1. 拡張機能付きの Rational UML モデリング製品を開くときは、必ず Visual Studio 2005 Standard または Professional Edition が開いていなければなりません。
注: インストール・ガイドには、ソフトウェア要件として「Visual Studio 2005」がリストされています。 これは「Visual Studio 2005、Standard Edition または Professional Edition」に訂正されます。Express 版はサポートされません。
2. 以前に Rational XDE から Rational Software Architect バージョン 6.x にインポートしたモデルの使用
以前に Rational XDE から Rational Software Architect バージョン 6.x にインポートしたモデルをお持ちで、それらを Rational Software Architect バージョン 7.0.0.1 にマイグレーションして (またはマイグレーションする計画があり)、さらに拡張機能も使用する場合は、Rational Software Architect の Rational XDE モデルのインポート機能もインストールしておく必要があります。
3. モデル内のパッケージに名前を付けるときは、パッケージ名の中で「.」(ドット) を使用しないでください。例えば、‘com’ の中の ‘ibm’ の中に ‘xtools’ がネストされたパッケージが必要である場合、“com.ibm.xtools” という単一のパッケージの名前を付けるのではなく、階層パッケージ構造を使用して、“xtools” をネストするパッケージ “ibm” をネストする、“com” というパッケージを作成します。この記法を使用すると表記が常に一意になるため、コードをモデルに変換する際の誤った融合の変更が減少します。
4. C# ステレオタイプは、ステレオタイプ・プロパティーを使用して C# 固有の値を設定する必要がある場合にのみ適用してください。そうしないと、同一のコードがステレオタイプを適用しないで生成された場合に、C# から UML への変換によって、以前の UML から C# への変換でステレオタイプがまったく使用されていないものと見なされ、「調整 (Reconcile)」ウィンドウが開いて、UML モデルからステレオタイプを除去する必要があることを示すデルタが表示されます。
5. C# プロファイルは、現在制約が未定義であるため、適用されたステレオタイプの無効な組み合わせが検出されません。プロファイルのステレオタイプの無効な使用をしないようにしてください。例えば、<<CSharpClass>> および <<CSharpInterface>> を両方とも適用することは無効であり、予測不能な変換動作が発生します。
6. 部分型をモデル化するときは、ユーザーが部分型として 1 つの空の型を使用し、そこにそれぞれの型が依存型として表示されるようにします。モデルの単一パッケージ内に、モデル化された空の部分型 (ソース) と定義済みの部分型 (ソースと依存関係がある) を含めます。この方法により、部分型のすべての部分がモデルの単一パッケージ内で定義されます。ソース名が型名として使用され、その他の部分の名前は型名として使用されません。マッピング・モデルを使用すると、各部分は異なるファイルに送信される場合があります。コードからモデルへの変換中に、各部分に対してユーザーが使用した名前は認識されず、その結果、変換によって <typename>_<filename> のような名前が生成され、融合ダイアログで差異として表示されます。
7. C# では総称型は、型パラメーターの値を指定した場合に限り使用できます。つまり、総称型の新しい型は、その型パラメーターをバインディングすることによって構成する必要があります。従って、パラメーター T を指定した List クラスは、List<String> などを使用することによって使用可能になります。UML では、このような構造型はテンプレート・バインディングとして表され、これらの型の名前は、コードを UML に変換して一時モデルを生成する際には存在しません。従って、構造型は無名型名として表され、融合ダイアログで差異として表示されます。ユーザーはそれをターゲット・モデルにある実際のテンプレート・バインディングにマップする必要があります。
多重定義した演算子は、操作としてモデル化されます。例えば、クラス C1 のコンテキストで次の 2 つの演算子を多重定義し、このタスクを Modeling Extension for Microsoft .NET を使用してモデル化したいと考えているとします。
等しい (==)
等しくない (!=)次のステップで、この例を使用して演算子の多重定義をモデル化する方法を説明します。
前提条件:
UML モデルはすでに作成または開かれている必要があります。多重定義した演算子をモデル化する手順は、次のとおりです。
- UML モデル内に C1 という名前の新規クラスを作成します。
- クラス C1 に新規操作を追加し、演算子 != と名前を付けます。この演算子には、多重定義される演算子 != の実装が含まれます。
- 次のように演算子を定義します。
a. 新しく作成した操作の可視性を public に設定します。
b. 新しく作成した操作の修飾子を static に設定します。
c. 新しく作成した操作の戻りの型を <Primitive Type> ブールに設定します。
d. 新しく作成した操作に型 C1 の 2 つのパラメーターを追加し、c1、c2 と名前を付けます。- もう 1 つの操作をクラス C1 に追加し、演算子 == と名前を付けます。この演算子には、多重定義される演算子 == の実装が含まれます。
- ステップ 3 に沿って演算子を定義します。
クラス C1 のコンテキストでの多重定義した演算子 != および == のモデル化が完了しました。
これらのリリース・ノートには、製品資料が最終的に完成するまで利用不能であった問題および制限など、リリース固有の情報が含まれています。
モデリング拡張ソフトウェアでインポートされたコードが正しくコンパイルされなかった場合、通知は行われません。インポートされた C# プロジェクトに構文エラーがあっても、モデリング拡張ソフトウェアでは、エラーを示すフラグがプロジェクト・エクスプローラーまたは Visualizer のダイアグラムに表示されません。
解決策: 変換を行う前、および Modeling Extension for Microsoft .NET にインポートする前に、必ず C# コードが Visual Studio.NET で正常にコンパイルされることを確認してください。
- Modeling Extension for Microsoft .NET は、開いている Visual Studio 2005 の最初のインスタンスのみを認識し、それと通信します。 Modeling Extension for Microsoft .NET が使用されているマシン上では、1 度に 1 つの Visual Studio のインスタンスのみ実行してください。
- Modeling Extension for Microsoft .NET の実行中に、Visual Studio 内で、別のソリューション (インポートされたもの以外) を閉じたり開いたりしないでください。
- 常に Visual Studio 2005 の 1 つのインスタンスを開いた状態にしてください。Modeling Extension for Microsoft .NET は、Visual Studio 2005 の最初のインスタンスのみを認識して、それと通信します。
- Modeling Extension for Microsoft .NET にソリューションをインポートすると、ソリューション内に存在するすべての C# プロジェクトに対応する Eclipse プロジェクトが、Eclipse ワークスペースに作成されます。Eclipse で作成されるプロジェクトの名前は、Visual Studio 2005 ソリューション内の C# プロジェクトと同じ名前になります。プロジェクトについて注意すべき重要な点は、次のとおりです。
- Eclipse で作成されたプロジェクトは、Visual Studio 2005 ソリューションの対応する C# プロジェクトで使用される C# ファイルおよび .NET アセンブリーとリンクします。これらのリンクは、Eclipse で Modeling Extension for Microsoft .NET から Visual Studio 2005 のプロジェクトおよびその内容についての情報を検索、更新、および表示するための唯一の手段です。実際にはリンクは、Eclipse で C# プロジェクトのビューとして機能します。
- UML から C# への変換の使用を除き、インポートされたプロジェクトを Eclipse 機能を使用して変更しないでください。Eclipse 機能を使用して、これらのプロジェクトの名前を変更したり、そのコンテンツを変更したりすると、予測不能な結果が発生することがあります。特に、プロジェクト内に UML モデル (.emx) またはダイアグラム・ファイル (.dnx) を作成または追加することは避けてください。これらの目的を達成するには、その代わりに、Eclipse 内に別個のプロジェクト (例えば UML プロジェクト) を作成します。インポートされたプロジェクト内にダイアグラム・ファイル (.dnx) を作成しないようにするには注意が必要です。これは、新規のダイアグラムが作成されると、可視化フレームワークが、それらのロケーションを、視覚化された要素があるプロジェクトにデフォルトで指定するためです。
- インポートされたプロジェクトを閉じてから再度開いても、問題はありません。また、それらを削除しても問題ありませんが、「それらの基礎になっているコンテンツは削除しないでください」 (どうしても Visual Studio プロジェクトおよびそのすべてのコンテンツを削除する必要がある場合は、Visual Studio から行ってください)。
- Eclipse に Visual Studio 2005 ソリューションをインポートした後は、Visual Studio 2005 内の C# プロジェクトの名前を変更しないようにしてください。プロジェクトの名前を変更する必要がある場合は、以下のステップに従って行ないます。
- 対応する (インポートされた) Eclipse プロジェクトを削除します (ただし、「それらの基礎になっているコンテンツは削除しないでください」)。
- Visual Studio 内でそのプロジェクトの名前を変更します。
- Visual Studio ソリューションを再インポートします (Modeling Extension for Microsoft .NET ソリューションは追加的にソリューションをインポートすることができます。この機能は、新規に追加された C# プロジェクトを Visual Studio 2005 ソリューションにインポートする場合にも便利です)。
- Modeling Extension for Microsoft .NET での操作を実行する前に、C# プロジェクトに構文エラーが含まれておらず、また、それらのプロジェクトが Visual Studio 2005 内で正常にコンパイルされることを確認してください。Modeling Extension for Microsoft .NET は、Visual Studio のコード・モデル API を使用して C# ファイルの構文解析を行ないます。C# ファイルにエラーがあると、これらの API から誤った結果および NULL 値が戻されます。例えば、Visual Studio で C# ファイルを変更してから、そのプロジェクトを Eclipse で最新表示すると、ファイルがプロジェクト・エクスプローラーで拡張できないことが表示されます。これは、おそらくその変更によって C# の構文エラーが発生したためです。
推奨される解決策は、Visual Studio 2005 に切り替えて、構文エラーをすべて修正し、そのソリューションを再ビルドしてからインポートされたプロジェクトを Eclipse で最新表示することにより変更点が反映されるようにすることです。変換を適用するときには、Visual Studio ソリューションをクリーンなビルド状態にしておくことが特に重要です。- Modeling Extension for Microsoft .NET は、COM メカニズムを使用して Visual Studio 2005 と同期します。 Visual Studio がビジーになっていると、COM の呼び出しが失敗したり拒否されたりすることがあります。 Modeling Extension for Microsoft .NET で以下の操作を実行するときは、Visual Studio 2005 を操作したり、アクティブにしたりしないでください。
- .NET ソリューションのインポート
- プロジェクトの最新表示
- プロジェクト・エクスプローラー内でインポート済みのプロジェクトまたはファイルを展開すること (例えば、ツリー・ビューの展開)
- Visual Studio 2005 ソリューションが以前にインポートされたワークスペースで Modeling Extension for Microsoft .NET を始動すること
- .NET 可視化ダイアグラムの合成
- UML から C# または C# から UML への変換
- .NET フレームワーク・アセンブリー内に定義された型のコンテンツの探索 (例えば、その型に含まれる操作やフィールドの検索) を計画していない場合は、Visual Studio 2005 ソリューションを Eclipse ワークスペースにインポートするときに、「.Net アセンブリーの構文解析中に「型」のみを取得」オプションを使用します。このオプションは、.NET ソリューション・インポート・ウィザードの最初のページで選択可能です。このオプションを有効にすることにより、ソリューションのインポート速度が上がり、C# および .NET 型の視覚化の速度が上がります。
- Visual Studio 2005 では、変更を自動ロードするためのオプションを常に有効にしてください。「オプション (Options)」ウィンドウの「環境 (Environment)」->「文書 (Documents)」ページで表示される「自動ロードの変更 (Auto Load changes)」ボックスにチェック・マークを付けると、このオプションが有効になります。これは、「ツール-オプション (Tools-Options)」->「環境 (Environment)」->「文書 (Documents)」->「ファイルが環境の外で変更された場合に検出 (Detect When a file has changed out side the environment)」->「保存された場合の自動ロードの変更 (Auto Load changes, if saved)」によって開くことができます。
- インポートしたプロジェクトのコンテキスト・メニューから「プロパティー」オプションを選択することにより、Eclipse で C# プロジェクトのエンコードを変更できます。 通常、Visual Studio プロジェクトは大きいため、このエンコードは通常以上に時間がかかることに留意してください。
ネストされた class/struct/interface を使用して外部の class/struct/interface に要素タイプを定義する場合は、タイプおよび要素が同じクラスで定義されていたとしても、型名に外部の型の名前が含まれます。 この時点では、既知の解決策がありません。 今後のバージョンで取り組まれる課題です。
例えば、以下のモデルを使用すると、
- OuterClass
+ InnerClass
+ attribute1 : InnerClassOuterClass.cs 内に InnerClass として生成されるコードの一部として、以下が作成されます。
private OuterClass.InnerClass attribute1;
クラス名、資料などの UML モデルに存在するユニコード文字の順方向変換は、このリリースではサポートされません。ユニコード文字はすべて、対応する C# ファイル内で '?' として生成されます。
Modeling Extension for Microsoft .NET が IBM Rational Software Modeler と共にインストールされている場合、Modeling Extension for Microsoft .NET 機能を例示するビューレット・ツアーは、「ようこそ」画面で、「概要 (Overview)」 > 「別のモデリング・アプローチ... (Different modeling approaches...)」 > 「モデル変換の詳しい説明 (More about model transformations)」をクリックしても使用できません。このツアーは、チュートリアル・ギャラリーで使用できます。
Rational Software Modeler でツアーを表示するには、「ヘルプ」 > 「チュートリアル」をクリックし、「ツアー (Tours)」を展開してから、「UML モデルの C# コードへの変換 (Transforming UML models into C# code)」をクリックしてください。「ツアーの開始 (Start tour)」をクリックしてビューレットを始動します。
場合によっては、マッピング・オプションおよび「ソースとターゲットの間の関係を作成」オプションを使用して UML から C# への変換を再実行したときに、生成されたコードが破損することがあります。例えば、コード・コメント上の "/" が欠落したり、その他のコード・エラーが発生する可能性があります。
これは、using によってコードを 1 つの .cs ファイルに結合することもコードを 2 つのファイルに分割することもできるように、マニフェストの関係が成果物間で移動しているときに発生します。
この問題は、将来のリリースで修正する予定です。
インポートされた XDE コード・モデルで最初に C# から UML への変換を実行すると、調整ダイアログ・ボックスに、ステレオタイプに関連する多くの相違点が表示されます。 これは、インポートされたモデル内の XDE に関連したステレオタイプが、C# から UML への変換によって認識されないためです。この問題は、将来のリリースで修正する予定です。
解決策:
XDE コード・モデルをインポートした直後に (モデルまたはコードに変更を行なう前に) ワンタイム「クリーンアップ」変換を実行します。 C# から UML への変換を実行します。 調整ダイアログが表示されたら、 一時モデル (左側のペインに表示されるモデル) のために推奨された変更点について、すべて同意します。 これにより、永続モデルからステレオタイプが除去されるので、その後 C# から UML への変換を実行するときには、相違点は報告されなくなります。
<<CSharpProperty>> や <<CSharpField>> などのようにステレオタイプ化された UML プロパティーを含むモデルで、それらの型が設定されておらず、ソース・コードがこれらの要素のデータ・タイプとしてアセンブリーの型を指定しているとします。C# から UML への変換がこのようなコードおよびターゲット・モデル上で実行される場合、FUSE は要素に設定されるデータ・タイプ (UML vizref になります) を正しく表示しますが、操作が完了するとそれらの要素のデータ・タイプが欠落 (null) してしまいます。 これは、既知の問題であり、将来のリリースで修正する予定です。
モデルのファイル名に # 記号が含まれており、それが C# から UML への変換のターゲットとして指定されている場合、FUSE ダイアログ・ボックスで、相違点をマージするための一時モデルとターゲット・モデルを 2 つのペインに表示することができません。 この問題は、将来のリリースで修正する予定です。
インポートされた XDE モデルが C# から UML への変換のターゲットとして指定されており、また、変換構成でマッピング・モデルが指定されている場合、C# から UML への変換が「NULL ポインター例外」で失敗します。この問題は、マッピング・モデルのある XDE インポート済みモデルでのみ発生します。
解決策:
インポートされたモデルからパッケージ <<Aritifacts>> を削除してから、変換を実行してください。成果物パッケージの削除によって、情報が失われることはありません。マッピング・モデルには、さまざまなファイルなどに関する情報が入るためです。この問題は、将来のリリースで修正する予定です。
変換構成エディターで「新規ターゲット・コンテナーの作成」ボタンを使用してターゲット・モデルが作成される場合、フォーカスが新規に作成されたモデルに移動し、ターゲット・ペインで新規モデルが選択されないことがあります (C# から UML への変換が前方変換である場合)。
解決策:
手動で構成エディターに切り替えて、ターゲット・モデルを選択してください。 これは、既知の問題であり、将来のリリースで修正する予定です。
UML から C# への変換が、変更されたマッピング・モデルで実行され、ファイルが削除されるようになる場合、およびユーザーが「ファイルの削除 (File Deletion)」ダイアログ・ボックスでそのファイルの削除を選択した場合、ファイルは実際には削除されません。そのコンテンツを保持するため、ファイルがプロジェクトから除去されるだけです。
後で、UML から C# への変換を再度実行して、前のステップで削除された (プロジェクトから除去された) ファイルが再作成されるようにすると、この (再作成された) ファイルには新しいコンテンツではなく古い (元の) コンテンツが入ります。
解決策:
この問題の現時点での解決策は、ステップ 1 の後でこのようなファイルをファイル・システムから削除することです。以下から、このようなファイルのリストを入手することができます。
- 変換がサイレント・モードで実行されていない場合は、「ファイルの削除 (File Deletion)」ダイアログ・ボックス。
- 変換がサイレント・モードで実行されるように構成されている場合は、プロジェクトに属するファイルと比較されるファイル・システム上で使用可能なファイルのリスト。
- マッピング・モデル内の空の成果物のリスト (存在する場合)。
C# コードから @generated タグを除去した後に、変換構成の「共通」ページで「ソースとターゲットの間の関係を作成」オプションを選択して UML から C# への変換を再適用すると、コードの中に余分な URI タグが生成されます。この現象は変数でのみ見られます。
URI タグは以下のように形成されます:
//@C#_transform [
// _URI=platform:/resource/UML%20project/Blank%20Model%20t1.emx#_cd19cKJhEdurjYIa4vhLGA//]
再適用を複数回実行すると、C# ファイル内に、さらに URI タグが生成されます。
解決策:
この問題の既知の解決策はありません。
生成済みの setter の @generated タグが除去され、そのタイプのコードが UML から C# への変換の再実行の前に変更されると、余分な setter が生成されます。
解決策は、モデル内でタイプ変更を行なうことです。
「UML 要素の置換」オプションを選択して UML から C# への変換を実行すると、UML モデル内の列挙リテラルは置き換えられません。 列挙型 E に 2 つのリテラル L1 および L2 があり、E がパッケージ p に入っている場合、変換を実行した後、列挙型 E はコード内に生成された C# 列挙型へのショートカットに正常に置き換えられますが、リテラル L1 および L2 は変換の後もパッケージ p の中にあります。
解決策:
この問題の既知の解決策はありません。
XDE C# コード・モデル・インポーター (「ファイル」 -> 「インポート」 -> 「その他」 -> 「XDE .Net ソリューション」) が、いくつかの事例で C# インデクサーを正しくマイグレーションしないことがあります。XDE .Net ソリューションに含まれる C# プロジェクトを、対応する UML モデルを指定することによってインポートし (.emx ファイルは、XDE 基本モデル・インポーターを使用してインポートされたものです)、次にマイグレーションされたモデルをソースとし、マイグレーションされたプロジェクトをターゲットとして UML から C# への変換を実行すると、この処理の前にコード内に存在したものと同じ setter にならないことがあります。場合によっては、setter がまったく生成されず、またある場合には、setter が余分なパラメーターと共に (名前値付きで) 生成され、コンパイル・エラーが出ます。これは、C# が setter の明示的パラメーターとして名前値を許可しないためです。
解決策:
この問題の既知の解決策はありません。
変換構成エディターの「共通」ページの「UML 要素の置換 」オプションを選択し、マッピングを使用して UML から C# への変換を実行すると、フォルダー内にソース・ファイルが生成される対象となるソース・モデル内の UML 要素が、変換によって置き換えられません。ターゲット C# プロジェクトのルート・フォルダーの下にコードが生成される対象となる UML 要素のみが、コード内の対応する要素へのショートカットに置き換えられます。
解決策:
UML から C# への変換を初めて実行すると、UML モデルおよびマッピング・モデルが編集中とマークされます。変換構成やマッピング・モデルを一切変更しないで、もう 1 回変換を実行してください。 これでモデル内のすべての UML 要素がショートカットに置き換えられます。
Rational XDE コード・モデルをインポートすると、それらのコード・モデルで参照されている、 いわゆる「アセンブリー・モデル」(「システム・モデル」または「参照モデル」とも呼ばれています) もすべて、インポートされ、Eclipse ベースの環境内で参照されます。 その結果、インポートされたコード・モデルを開くには、長時間かかることがあります。
解決策:
コード・モデルが正常にインポートされた後で、インポートされたアセンブリー・モデルを削除してください。 この解決策は、インポートされたコード・モデルの UML 要素を直接コード参照で置き換えて「混合モデリング」理論の操作を使用するか、 コード・モデルの UML 要素を保存して「true round-trip engineering (RTE)」理論の操作 (順方向と逆方向の変換と調整を反復する操作) を使用する場合に、 使用できます。解決策の効果:
1. アセンブリー・モデルを削除すると、インポート済みコード・モデルのオープンと編集をさらに速く行えるようになります。2. 本製品では、インポート済みのコード・モデルを開くと、「欠落している」参照先モデルに関する警告 または「エラー」が表示されることがあります。 このような警告は無視してかまいません。
3. 本製品では、インポート済みコード・モデルに対して検証を実行すると、「欠落している」参照先モデルに関する警告 または「エラー」が表示されることがあります。 これらは無視してかまいません。
例:
Project1 という名前の Visual Studio 2003 C# プロジェクトがあり、それに対応する XDE 基本モデル、Project1.mdx があるとします。 このモデルが、次の 5 つのシステム・モデルを参照しているものとします: System.mdx、mscorlib.mdx、System.Data.mdx、System.Web.mdx、および System.Drawing.mdx。- 最初に、VS 2005 マイグレーション・ユーティリティーを使用して、VS 2003 プロジェクトを VS 2005 にマイグレーションします。
XDE モデル・インポート (「ファイル」>「インポート」>「その他」>「Rational XDE モデル」) を使用して、プロジェクト・モデル Project1.mdx をインポートします。 その参照先モデルをすべてインポートすることを選択します (インポーターでは、インポート・プロセス時のモデルの保全性を確保するために、このことが必要です)。- この結果、6 個の .emx ファイルが Eclipse ワークスペースに作成されます。 作成されるファイルは、“Project1.emx”、“System.emx mscorlib.emx”、“System.Data.emx”、“System.Web.emx”、および “System.Drawing.emx.” です。
- 次に、Visual Studio 2005 Solution をインポートします (「ファイル」>「インポート」>「その他」 >「.Net ソリューション」)。 そのソリューションで既存の .mdx モデルが検出され、インポートされるコード・モデルの名前を 入力するよう求められます。 この場合、入力する名前は「Project1.emx」です。 またこの段階で、Project1.emx の UML 要素を、インポートしたソリューション内のコードへの参照と置き換えるかどうかを 選択することもできます。 「混合モデリング」を試してみたい場合はこのオプションを使用してください。 ただし、「true RTE」を試す場合は、このオプションを使用しないでください。
- これで、インポート・プロセスが完了しました。 次にプロジェクト・モデル「Project1.emx」を開いたときに、UML フレームワークが 5 個の参照先モデルをすべてロードして、「Project1.emx」内の要素から それらの参照先モデル内の要素への参照を解決しようとします。 これが原因で、インポートされた XDE モデルを開いて操作する場合に遅延が生じます。
- このパフォーマンス上不利な振る舞いを解消するには、5 個のインポートされたアセンブリー・モデルのそれぞれを、 選択して、削除してください。 上に述べたように、これによってパフォーマンスが改善され、また「Project1.emx」のオープンや検証を行う際に 警告や「エラー」が現れます。 ただし、警告やエラーが現れても、「Project1.emx」で実行するモデリングおよび変換のどの操作に もマイナスの影響があるわけではありません。
C#-to-UML 変換がサイレント・モードで実行され、かつ変換構成エディターでその他のオプションをすべて選択した場合、変換が失敗します。 具体的には、ターゲット・モデルへの新規の変更のなかに、サイレント・モードでマージされるステレオタイプ要素 ( たとえば、<<CSharpStruct>>) が含まれているときに、この現象が発生します。 この問題は、将来のリリースで修正する予定です。
!= または == のような多重定義演算子が含まれているソース・ファイルで、 これらの演算子をターゲット・モデルに取り込むために、C#-to-UML 変換が実行された場合、これ以降に、コードになにも変更を加えずに変換を実行したとき、FUSE ダイアログ・ボックスには変更点が表示されないはずです。 ただし、FUSE ダイアログ・ボックスには、パラメーターの名前変更に関連する変更が不正確に表示されます。
この問題は、将来のリリースで修正する予定です。
C# の変換では、 コードをどのように編成するかを表すファイル・システム階層のみを指定する場合には、 マッピング・モデルを使用する必要があります。 マッピング・モデルによるクラスやインターフェースなどの名前変更はまだサポートされていません。 C# アプリケーションの設計は、2 つのパースペクティブで実行することができます。
1. 論理システム設計
2 物理システム設計 (マッピング・モデルとして指定されます)
論理設計モデルには通常、さまざまなネームスペース、各種の型および継承関係、属性、関数が含まれます。
マッピング・モデルを使用する物理設計パースペクティブには、C# 変換のためのデプロイメント情報も組み込まれます。 つまり、変換でさまざまな論理構成体を各種のファイルに配置する仕方を、制御できます。 デフォルトでは、マッピング・モデルを使用しない UML から C# への変換では、それぞれの型 (たとえば、クラスまたはインターフェース) を、その型の名前と同じ名前で、 Visual Studio プロジェクトのルート・フォルダーに配置されたファイルに生成します。 たとえば、マッピング・モデルがない場合、 クラス「MyClass」は、「MyClass.cs」というファイルに生成されます。 ただし、ユーザーが 「Test.cs」というファイルにコードを生成させたい場合には、そのクラス「MyClass」を明示する成果物によって これをマッピング・モデルに指定する必要があります。
マッピング・モデルは、コードの生成のためのフォルダーまたはファイル階層を指定する場合にのみ使用します。 マッピング・モデルを使用しても名前変更は行えません。
論理設計 (変換ソース・モデル) と物理設計 (変換マッピング・モデル) の両方とも UML モデルであるにすぎない、という点に留意してください。違いは以下の点のみです。
- 論理ソース・モデルの UML パッケージは C# ネームスペースを表す。
- マッピング・モデルの UML パッケージは、ファイル・システム上のフォルダーを表す。
マッピング・モデル・オプションを使用可能にし、UML 要素の置換 オプションにチェック・マークを付けて UML から C# への変換を実行した後に、その変換を取り消した場合、 マッピング・モデルが不適切な状態になります。UML から C# への変換を、不適切なマッピング・モデルを使用して再度実行すると、C# ファイルが 誤った場所に生成されます。
解決策:
UML から C# への変換を再度実行する前に、マッピング・モデルへの変更を手動で取り消す必要があります。その方法の 1 つは、 マッピング・モデルを閉じ、変更を保存しないように選択することです。
IBM Rational ソフトウェア・サポートは、技術支援を提供します。
サポートが必要な場合の連絡先、およびガイドラインや参照資料については、「IBM Software Support Handbook」を参照してください。
よくある質問、既知の問題とフィックスのリスト、およびその他のサポート情報については、 IBM Rational ソフトウェア・サポート Web サイトにアクセスしてください。
Rational ソフトウェア製品のニュース、イベント、およびその他の情報については、 IBM Rational ソフト ウェア Web サイトにアクセスしてください。
IBM Rational ソフトウェア・サポートに連絡する前に、問題の説明に必要な背景情報を収集してください。 IBM ソフトウェア・サポート・スペシャリストに問題を説明するときは、 できる限り具体的に、かつ、関連するすべての背景情報も含めれば、 サポート・スペシャリストから、問題を効率よく解決するための支援を受けることができます。 時間を節約するために、以下の質問の答えを用意してください。
- 問題が発生したとき実行していたソフトウェアのバージョンは何ですか。
- 問題に関連するログ、トレース、およびメッセージがありますか。
- 問題を再現できますか。再現できる場合、それを再現するためにどんなステップを実行しますか。
- その問題の回避方法はありますか。ある場合は、その回避方法の説明を用意してください。
© Copyright IBM Corporation 2007. All Rights Reserved.
本書は米国 IBM が提供する製品およびサービスについて作成したものであり、 本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。 日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。 本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の 製品、プログラム、またはサービスを使用することができます。 ただし、IBM 以外の製品とプログラムの操作またはサービスの 評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について 実施権を許諾することを意味するものではありません。 実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
〒106-8711
東京都港区六本木 3-2-12
IBM World Trade Asia Corporation
Intellectual Property Law & Licensing
以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、 商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含む すべての明示もしくは黙示の保証責任または保証条件は適用されないものとします。 国または地域によっては、法律の強行規定により、保証責任の制限が 禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。 本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、 改良または変更を行うことがあります。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムと その他のプログラム (本プログラムを含む) との間での情報交換、 および (ii) 交換された情報の相互利用を可能にすることを目的として、 本プログラムに関する情報を必要とする方は、下記に連絡してください。
Intellectual Property Dept. for Rational Software
IBM Corporation
20 Maguire Road
Lexington, MA
02421-3112
USA本プログラムに関する上記の情報は、適切な使用条件の下で使用すること ができますが、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他の ライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、 IBM より提供されます。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、 もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、 他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。
IBM の将来の方向または意向に関する記述については、 予告なしに変更または撤回される場合があり、単に目標を示しているものです。
商標
以下は、IBM Corporation の商標です。
- developerWorks
- IBM
- Rational
Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国における商標です。
Microsoft、Windows、Windows NT は、Microsoft Corporation の米国およびその他の国における商標です。
Intel および Pentium は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。
UNIX は The Open Group の米国およびその他の国における登録商標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。