IBM Form Nummer: GC12-3888-00
© Copyright International Business Machines Corporation 2007. Alle Rechte vorbehalten.
© Copyright IBM Deutschland GmbH 2007. Alle Rechte vorbehalten.
Die aktuellste Version dieses Dokuments finden Sie unter
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/radce/70/docs/readme/readme.html.IBM® Rational® Modeling Extension für Microsoft® .NET ist eine C#- und CTS-Modellierungserweiterung für Rational-UML-Modellierungsprodukte. Diese Familie der Design- und Entwicklungstools ist auf dem Open-Source-Eclipse-Framework aufgebaut. Die Software Modeling Extension für Microsoft .NET schließt Plug-ins ein, die es Softwarearchitekten und modellorientierten Entwicklern ermöglichen, C#-Anwendungen und CTS-Typen darzustellen und einen optimal konzipierten C#-Code unter Verwendung von UML2 (Unified Modeling Language 2) zu erstellen.
Rational Modeling Extension für Microsoft .NET bietet Ihnen folgende Möglichkeiten:
- Import von .NET-Lösungen aus Microsoft Visual Studio 2005 für die Erstellung eines Spiegelimages der Lösung im Eclipse-Projekt.
- Visualisierung von C#-Anwendungen
- für Architekturerkennung und Abhängigkeitsanalyse mit Hilfe von Anzeigediagrammen.
- zum Dokumentieren der Anwendungsstruktur mit Hilfe von Klassendiagrammen.
- zum Dokumentieren von 'Wie-implementiert'- und 'Was-wäre-wenn'-Klasseninteraktionen mit Hilfe von Ablaufdiagrammen.
- zur Darstellung von .NET-Typen in Diagrammen in UML-Modellen als Bestandteil der Theorie der Operationen über die "gemischte Modellierung".
- Umsetzung von UML-Modellen in C#-Code
- Umsetzung von Änderungen im C#-Code ins UML-Modell
Die neuesten Details zu den Installationsvoraussetzungen enthält die aktualisierte Version dieser Readme-Datei unter http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.
Sie können das Installationshandbuch für Ihr Produkt auch im Installationsassistenten und im Dokumentationsverzeichnis der Produkt-CD anzeigen.
Für Rational Modeling Extension für Microsoft .NET sind IBM Installation Manager v1.0.0.2 oder höher sowie IBM Rational Software Architect, IBM Rational Software Modeler oder IBM Rational Systems Developer Version 7.0.0.1 erforderlich. Die Softwareinstallation wird nicht fortgesetzt, wenn die erforderlichen Versionen nicht installiert sind.
Informationen zur Installation von IBM Rational Modeling Extension für Microsoft .NET Version 7.0 enthalten die Installationsanweisungen im Web unter http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/install_instruction/install.html.
Sie können das Installationshandbuch für Ihr Produkt auch im Installationsassistenten und im Dokumentationsverzeichnis der ersten Produkt-CD anzeigen.
Die Software für die Modellierungserweiterung kann in die allgemein verfügbare Erstellung von IBM Rational Software Architect v7.0.0.1, IBM Rational Software Modeler v7.0.0.1 oder IBM Rational Systems Developer v7.0.0.1 installiert werden. Die folgende Prozedur gibt einen Überblick über den Installationsprozess. Weitere Einzelheiten finden Sie im Installationshandbuch zu IBM Rational Modeling Extension für Microsoft .NET.
Gehen Sie zum Installieren wie folgt vor:
- Stellen Sie sicher, dass ein Rational-UML-Modellierungsprodukt wie oben angegeben installiert ist.
- Wählen Sie in IBM Installation Manager aus, mit welchem Hostprodukt die Modellierungserweiterung installiert werden soll.
Die Modellierungserweiterung nutzt die Shell gemeinsam mit dem Hostprodukt und verwendet dieselbe Eclipse-Instanz.- Befolgen Sie die Anweisungen im Assistenten 'Installation Manager', und schließen Sie die Installation der Modellierungserweiterung ab.
Diese Release-Informationen enthalten Informationen, die erst nach Abschluss der Produktdokumentation verfügbar waren. Verwenden Sie die folgenden bewährten Verfahren und Richtlinien für die Modellierung von .NET-Anwendungen mit dem C#-Profil.
1. Visual Studio 2005 Standard oder Professional Edition muss geöffnet sein, wenn das Rational-UML-Modellierungsprodukt mit der Erweiterung geöffnet wird.
Hinweis: Im Installationshandbuch wird "Visual Studio 2005" als Softwarevoraussetzung aufgelistet. Dies wird zu "Visual Studio 2005, Standard Edition oder Professional Edition" erweitert. Die Express-Editionen werden nicht unterstützt.
2. Vorher aus Rational XDE in Rational Software Architect 6.x importierte Modelle verwenden
Wenn Sie über Modelle verfügen, die vorher aus Rational XDE in Rational Software Architect Version 6.x importiert wurden und Sie diese vor Rational Software Architect Version 7.0.0.1 migriert haben (oder ihre Migration planen) und Sie auch die Erweiterung verwenden, muss auch die Rational XDE-Modellimportkomponente von Rational Software Architect installiert sein.
3. Verwenden Sie beim Benennen der Pakete im Modell nicht das Zeichen ‘.’ (Punkt) im Paketnamen. Wenn Sie zum Beispiel die verschachtelten Pakete ‘xtools’ in ‘ibm’ in ‘com’ benötigen, verwenden Sie anstatt eines einzelnen Pakets mit der Bezeichnung “com.ibm.xtools” eine hierarchische Paketstruktur, und erstellen Sie das Paket “com”, in dem “ibm” verschachtelt ist, in dem wiederum “xtools” verschachtelt ist. Diese Schreibweise ist immer eine eindeutige Darstellung und trägt dazu bei, falsche Fusionsänderungen bei Umsetzungen von Code in ein Modell zu reduzieren.
4. Wenden Sie C#-Stereotypen nur an, wenn Sie einige C#-spezifische Werte über die Stereotypeigenschaften festlegen müssen. Andernfalls setzt die C#-zu-UML-Umsetzung voraus. wenn der identische Code ohne Anwendung des Stereotyps generiert worden wäre, dass kein Stereotyp bei der vorherigen UML-zu-C#-Umsetzung verwendet wurde; im Fenster für die Abstimmung wird ein Delta mit dem Vorschlag darüber angezeigt, den Stereotypen aus dem UML-Modell zu entfernen.
5. Das C#-Profil definiert derzeit keine Integritätsbedingungen; daher werden ungültige Kombinationen angewendeter Stereotypen nicht ermittelt. Vermeiden Sie die ungültige Verwendung von Profilstereotypen. So ist zum Beispiel das gleichzeitige Anwenden von <<CSharpClass>> und <<CSharpInterface>> ungültig; es führt zu einem unvorhersehbaren Umsetzungsverhalten.
6. Beim Modellieren von Teiltypen muss der Benutzer einen leeren Typ als Teiltyp verwenden, für den jeder Abschnitt als abhängiger Abschnitt angezeigt wird. Schließen Sie den modellierten leeren Teiltyp (Quelle) und die definierten Teiltypen (mit Abhängigkeitsbeziehungen zur Quelle) in ein einziges Paket im Modell ein. Auf diese Weise werden alle Abschnitte des Teiltyps in einem Paket im Modell definiert. Der Name der Quelle wird als Typname verwendet, und der Name des anderen Abschnitts wird nicht als Typname verwendet. Bei der Verwendung eines Zuordnungsmodells kann jeder Teilabschnitt einer anderen Datei zugeordnet werden. Bei der Umsetzung von Code in ein Modell sind die Namen, die vom Benutzer für jeden Abschnitt verwendet wurden, nicht bekannt. Daher werden im Verlauf der Umsetzung die Namen im Format <typname>_<dateiname> generiert, was im Fusionsdialog als Unterschied angezeigt wird.
7. In C# können generische Typen nur verwendet werden, wenn wir die Werte für die Typparameter angeben; d. h., wird müssen einen neuen Typ für einen generischen Typ durch Binden seiner Typparameter erstellen. So kann z. B. die Klasse 'List' mit dem Parameter 'T' mit Hilfe von 'List<zeichenfolge>' verwendet werden usw. In UML werden solche konstruierten Typen als Schablonenbindungen und Namen dieser Tyoen dargestellt, wenn Code in UML zur Generierung ndes temporären Modells umgesetzt wird. Demzufolge werden die konstruierten Typen als anonyme Typennamen dargestellt, die als Unterschied im Fusionsdialog angezeigt werden. Der Benutzer muss eine Zuordnung zur tatsächlichen Schablonenbindung im Zielmodell erstellen.
Überladene Operatoren werden als Operationen modelliert. Nehmen Sie zum Beispiel an, dass Sie die folgenden zwei Operatoren im Kontext der Klasse C1 voraussichtlich überladen werden und diese Task gerne mit der Modeling Extension für Microsoft .NET modellieren würden.
Gleich (==)
Ungleich (!=)Die folgenden Schritte erläutern, wie die Überladung von Operatoren anhand dieses Beispiels modelliert werden kann.
Voraussetzungen:
Es muss ein UML-Modell erstellt oder geöffnet worden sein.Gehen Sie zum Modellieren der überladenen Operatoren wie folgt vor:
- Erstellen Sie im UML-Modell eine neue Klasse namens 'C1'.
- Fügen Sie zur Klasse C1 eine neue Operation hinzu, und nennen Sie sie Operator !=. Dieser Operator wird die Implementierung für den überladenen Operator != enthalten.
- Definieren Sie den Operator wie folgt.
a. Geben Sie als Sichtbarkeit der neu erstellten Operation 'öffentlich' (public) an.
b. Definieren Sie als Qualifikationsmerkmale für die neu erstellte Operation 'statisch'.
c. Geben Sie als Rückgabetyp für die neu erstellte Operation <Basiselementtyp> 'Boolean' an.
d. Fügen Sie zwei Parameter des Typs 'C1' zu der neu erstellten Operation hinzu, und benennen Sie sie 'c1' und 'c2'.- Fügen Sie zur Klasse C1 eine weitere Operation hinzu, und nennen Sie sie Operator ==. Dieser Operator wird die Implementierung für den überladenen Operator == enthalten.
- Definieren Sie den Operator wie in Schritt 3 beschrieben.
Die Modellierung der überladenen Operatoren '!=' und '==' im Kontext der Klasse 'C1' ist hiermit abgeschlossen.
Diese Release-Informationen enthalten für das Release spezifische Informationen wie zum Beispiel bekannte Einschränkungen, Probleme und Ausweichlösungen zur Umgehung von Problemen, die erst nach Abschluss der Produktdokumentation bekannt bzw. verfügbar waren.
Der Benutzer erhält von der Software zur Modellierungserweiterung keine Benachrichtigung darüber, dass der importierte Code nicht ordnungsgemäß kompiliert wurde. Wenn das importierte C#-Projekt Code mit Syntaxfehlern enthält, wird in der Software zur Modellierungserweiterung nicht die Markierung zur Angabe von Fehlern im Projektexplorer oder den Visualisierungsdiagrammen angezeigt.
Problemumgehung: Stellen Sie sicher, dass der C#-Code erfolgreich in Visual Studio .NET kompiliert wurde, bevor eine Umsetzung stattfindet und bevor Sie ihn in Modeling Extension für Microsoft .NET importieren.
- Modeling Extension für Microsoft .NET erkennt nur die erste Instanz von Visual Studio 2005, die geöffnet wird, und nur mit dieser ist eine Kommunikation möglich. Führen Sie immer nur eine Instanz von Visual Studio auf einer Maschine gleichzeitig aus, auf der Modeling Extension für Microsoft .NET verwendet wird.
- Schließen oder öffnen Sie nie eine andere Lösung (eine andere als die importierte) in Visual Studio, wenn Modeling Extension für Microsoft .NET ausgeführt wird.
- Lassen Sie immer eine Instanz von Visual Studio 2005 geöffnet; von Modeling Extension für Microsoft .NET wird immer nur die erste Instanz von Visual Studio 2005 erkannt, und nur mit dieser ist eine Kommunikation möglich.
- Wenn eine Lösung in Modeling Extension für Microsoft .NET importiert wird, werden Eclipse-Projekte im Eclipse-Arbeitsbereich für jedes entsprechende C#-Projekt erstellt, das in der Lösung enthalten ist. Das in Eclipse erstellte Projekt besitzt denselben Namen wie das C#-Projekt in der Lösung von Visual Studio 2005. Die folgenden Punkte sind für die Projekte von großer Bedeutung:
- Die in Eclipse erstellten Projekte verfügen über Links zu den C#-Dateien und .NET-Assemblys, die von den entsprechenden C#-Projekten in der Lösung von Visual Studio 2005 verwendet werden. Diese Links sind für Modeling Extension für Microsoft .NET die einzige Möglichkeit, Informationen zu den Projekten von Visual Studio 2005 und ihren Inhalt in Eclipse abzurufen, zu aktualisieren oder anzuzeigen. Eigentlich dienen sie zum Anzeigen der C#-Projekte in Eclipse.
- Vermeiden Sie, mit Ausnahme der Verwendung der UML-zu-C#-Umsetzungen, die Verwendung von Eclipse-Mechanismen zum Ändern der importierten Projekte. Die Verwendung von Eclipse-Mechanismen für die Umbenennung dieser Projekte oder die Änderung ihrer Inhalte kann zu unvorhersehbaren Ergebnissen führen. Vermeiden Sie insbesondere das Erstellen oder Hinzufügen von UML-Modellen (.emx) oder Diagrammdateien (.dnx) in den Projekten. Erstellen Sie zu diesen Zwecken stattdessen separate Projekte (wie zum Beispiel ein UML-Projekt) in Eclipse. Zur Vermeidung der Erstellung von Diagrammdateien (.dnx) in den importierten Projekten ist Vorsicht geboten, da das Visualisierungsframework bei der Erstellung neuer Diagramme standardmäßig die Projekte, in denen sich die visualisierten Elemente befinden, zu ihren Positionen macht.
- Sie können die importierten Projekte einfach schließen und wieder öffnen. Sie können sie auch einfach löschen; allerdings sollten Sie “zu Grunde liegende Inhalte nicht entfernen” (wenn Sie ein Visual Studio-Projekt und dessen sämtlichen Inhalt tatsächlich löschen müssen, verwenden Sie hierfür Visual Studio).
- Vermeiden Sie nach dem Import der Lösung von Visual Studio 2005 in Eclipse ein Umbenennen der C#-Projekte in Visual Studio 2005. Führen Sie die folgenden Schritte aus, wenn Sie ein Projekt umbenennen müssen:
- Löschen Sie das entsprechende (importierte) Eclipse-Projekt (aber “entfernen Sie den zu Grunde liegenden Inhalt nicht”).
- Benennen Sie das Projekt in Visual Studio um.
- Importieren Sie die Visual Studio-Lösung erneut; die Lösung von Modeling Extension für Microsoft .NET kann die Lösung inkrementell importieren; diese Funktion ist auch dann nützlich, wenn Sie neu hinzugefügte C#-Projekte in die Lösung von Visual Studio 2005 importieren.
- Stellen Sie vor der Ausführung von Aktionen in Modeling Extension für Microsoft .NET sicher, dass die C#-Projekte keine Syntaxfehler enthalten und dass sie in Visual Studio 2005 erfolgreich kompiliert werden. Von Modeling Extension für Microsoft .NET werden die Anwendungsprogrammierschnittstellen (API) für Codemodelle von Visual Studio zum syntaktischen Analysieren der C#-Dateien verwendet. Diese APIs geben falsche Ergebnisse und Nullwerte zurück, wenn in den C#-Dateien Fehler enthalten sind. Beispiel: Wenn Sie eine C#-Datei in Visual Studio ändern, anschließend das entsprechende Projekt in Eclipse aktualisieren und Sie sehen, dass die Datei im Projektexplorer nicht erweitert werden kann, wurden möglicherweise C#-Syntaxfehler durch die Änderung aufgenommen.
Es wird empfohlen, zu Visual Studio 2005 zu wechseln, alle Syntaxfehler zu korrigieren, die Lösung erneut zu erstellen und das importierte Projekt in Eclipse zu aktualisieren, damit die Änderungen wirksam werden. Es ist sehr wichtig, dass Visual Studio-Lösungen bei der Anwendung von Umsetzungen bereinigt und erstellt sind.- Von Modeling Extension für Microsoft .NET wird ein COM-Mechanismus zur Synchronisierung mit Visual Studio 2005 verwendet. Diese COM-Aufrufe können fehlschlagen oder zurückgewiesen werden, wenn Visual Studio beschäftigt ist. Arbeiten Sie nicht mit Visual Studio 2005, und versetzen Sie Visual Studio 2005 nicht in einen aktiven Status, wenn die folgenden Operationen in Modeling Extension für Microsoft .NET ausführt werden:
- Importieren von .NET-Lösungen.
- Projektaktualisierung.
- Erweitern von importierten Projekten oder Dateien im Projektexplorer (z. B. Erweiterung der Baumstruktursicht).
- Starten von Modeling Extension für Microsoft .NET in einem Arbeitsbereich, in dem zuvor eine Lösung von Visual Studio 2005 importiert wurde.
- Zusammenstellen eines .NET-Visualisierungsdiagramms.
- Ausführen einer UML-zu-C#- oder einer C#-zu-UML-Umsetzung.
- Wenn Sie nicht planen, den Inhalt von Typen zu durchsuchen, die in den .NET-Framework-Assemblys definiert sind (zum Beispiel nach den Operationen oder Feldern, die in den Typen enthalten sind), verwenden Sie beim Import der Lösung von Visual Studio 2005 in den Eclipse-Arbeitsbereich die Option "Beim Parsing der .Net-Assemblys nur Typen abrufen". Diese Option ist auf der ersten Seite des Assistenten zum Importieren einer .NET-Lösung verfügbar. Dies beschleunigt den Import der Lösung und auch die Visualisierung der C#- und .NET-Typen.
- Aktivieren Sie in Visual Studio 2005 immer die Option zum automatischen Laden der Änderungen. Wenn Sie das Feld “Änderungen automatisch laden" markieren, das im Fenster 'Optionen' auf der Seite 'Umgebung' -> 'Dokumente' verfügbar ist, wird diese Option aktiviert. Diese können Sie öffnen, wenn Sie 'Tools-Optionen' -> 'Umgebung' -> 'Dokumente' -> 'Änderungen an Dateien außerhalb der Umgebung erkennen' -> 'Änderungen beim Speichern automatisch laden' auswählen.
- Sie können die Codierung von C#-Projekten über Eclipse durch Auswählen der Option 'Eigenschaften' im Kontextmenü der importierten Projekte ändern. Beachten Sie, dass für diese Codierung mehr Zeit als für die normale Codierung erforderlich ist, da Visual Studio-Projekte normalerweise umfangreich sind.
Wenn eine verschachtelte Klasse oder Schnittstelle oder ein verschachteltes Struct zum Definieren des Elementtyps in einer äußeren Klasse oder Schnittstelle oder einem äußeren Struct verwendet wird, enthält der Typenname den Namen der äußeren Typen, auch wenn der Typ und das Element in derselben Klasse definiert sind. Derzeit gibt es keine bekannte Fehlerumgehung. Das Problem wird in der nächsten Version behoben.
Beispiel: Das folgende Modell
- OuterClass
+ InnerClass
+ attribute1 : InnerClassergibt im Rahmen des generierten Codes für InnerClass in OuterClass.cs Folgendes:
private OuterClass.InnerClass attribute1;
Die vorwärts gerichtete Umsetzung von Unicodezeichen in einem UML-Modell wie z. B. Klassennamen, Dokumentation usw. wird in diesem Release nicht unterstützt. Alle Unicodezeichen werden in den entsprechenden C#-Dateien als '?' generiert.
Wenn Modeling Extension für Microsoft .NET mit IBM Rational Software Modeler installiert ist, ist die Viewlet-Tour, die Modeling Extension für Microsoft .NET-Funktionen veranschaulicht, auf der Willkommensseite nicht verfügbar, die durch Klicken auf Übersicht > Verschiedene Ansätze zur Modellierung ... > Weitere Informationen zu Modellumsetzungen aufgerufen werden kann. Die Tour ist in der Lernprogrammsammlung verfügbar.
Wenn Sie die Tour in Rational Software Modeler anzeigen möchten, müssen Sie auf Hilfe > Lernprogramme klicken, Touren erweitern und anschließend auf UML-Modelle in C#-Code umsetzen klicken. Klicken Sie auf Tour starten, um das Viewlet zu starten.
In einigen Fällen wird der generierte Code beschädigt, wenn eine UML-zu-C#-Umsetzung mit den Optionen für die Zuordnung und das Erstellen von Quelle-zu-Ziel-Beziehungen erneut ausgeführt wird. Möglicherweise fehlt z. B. der Schrägstrich "/" in den Codekommentaren, oder es liegen andere Codefehler vor.
Dazu kommt es, wenn die Manifestbeziehung zwischen Artefakten verschoben wird, sodass durch die Verwendung Code in einer CS-Datei kombiniert oder in zwei Dateien unterteilt werden kann.
Dieses Problem wird in einem der nächsten Releases behoben.
Wenn eine C#-zu-UML-Umsetzung für ein importiertes XDE-Codemodell zum ersten Mal ausgeführt wird, werden im Dialogfenster für die Abstimmung viele stereotypenbezogene Unterschiede angezeigt. Dazu kommt es, weil die XDE-bezogenen Stereotypen im importierten Modell von der C#-zu-UML-Umsetzung nicht erkannt werden. Dieses Problem wird in einem der nächsten Releases behoben.
Problemumgehung:
Führen Sie eine einmalige "Bereinigungsumsetzung" unmittelbar nach dem Import des XDE-Codemodells aus (bevor Sie Änderungen am Modell oder am Code vornehmen). Führen Sie die C#-zu-UML-Umsetzung aus. Wenn das Dialogfenster für die Abstimmung angezeigt wird, akzeptieren Sie alle vorgeschlagenen Änderungen für das temporäre Modell (das Modell, das im linken Teilfenster angezeigt wird). Dies führt dazu, dass die Stereotypen aus dem gespeicherten Modell entfernt werden, sodass nachfolgende Ausführungen der C#-zu-UML-Umsetzung keine Unterschiede mehr melden.
Betrachten wir ein Modell mit stereotypisierten UML-Eigenschaften wie z. B. <<CSharpProperty>>, <<CSharpField>>, deren Typ nicht definiert ist und bei denen der Quellcode Assemblytypen als Datentypen für diese Elemente angibt. Wenn eine C#-zu-UML-Umsetzung mit solch einem Code und für solch ein Zielmodell ausgeführt wird, zeigt die Fusion den Datentyp (ein UML-VizRef) ordnungsgemäß an, der für das Element definiert wird; allerdings fehlt der Datentyp nach Beendigung der Operation für diese Elemente (null). Hierbei handelt es sich um ein bekanntes Problem, das in einem der nächsten Releases behoben wird.
Wenn eine Modelldatei das Symbol # enthält und als Ziel für eine C#-zu-UML-Umsetzung angegeben ist, kann das Fusionsdialogfenster die beiden Teilfenster mit dem temporären Modell und dem Zielmodell zum Zusammenführen der Unterschiede nicht anzeigen. Dieses Problem wird in einem der nächsten Releases behoben.
Wenn ein importiertes XDE-Modell als Ziel einer C#-zu-UML-Umsetzung angegeben ist und auch ein Zuordnungsmodell in der Umsetzungskonfiguration angegeben ist, schlägt die C#-zu-UML-Umsetzung mit einer Null Pointer-Ausnahme fehl. Dieses Problem tritt nur bei importierten XDE-Modellen mit Zuordnungsmodell auf.
Problemumgehung:
Löschen Sie das Artefaktpaket aus dem importierten Modell, und führen Sie anschließend die Umsetzung aus. Durch das Löschen des Artefaktpakets gehen keine Informationen verloren, da das Zuordnungsmodell über Informationen zu unterschiedlichen Dateien usw. verfügt. Das Problem wird in einem der nächsten Releases behoben.
Wenn ein Zielmodell über die Schaltfläche Neuen Ziel-Container erstellen im Umsetzungskonfigurationseditor erstellt wird, verschiebt sich der Fokus gelegentlich auf das neu erstellte Modell und das neue Modell ist nicht im Zielteilfenster ausgewählt (wo die C#-zu-UML eine vorwärts gerichtete Umsetzung ist).
Problemumgehung:
Wechseln Sie manuell zum Konfigurationseditor, und wählen Sie das Zielmodell aus. Hierbei handelt es sich um ein bekanntes Problem, das in einem der nächsten Releases behoben wird.
Wenn eine UML-zu-C#-Umsetzung mit einem geänderten Zuordnungsmodell ausgeführt wird (so, dass es zum Löschen einer Datei kommt) und sich der Benutzer über das entsprechende Dialogfenster zum Löschen der Datei entscheidet, wird diese Datei nicht wirklich gelöscht. Sie wird nur aus dem Projekt entfernt, damit der Inhalt bewahrt wird.
Wenn die UML-zu-C#-Umsetzung später erneut so ausgeführt wird, dass es zu einer Neuerstellung der im vorherigen Schritt gelöschten (aus dem Projekt entfernten) Datei kommt, verfügt diese (neu erstellte) Datei über den alten (ursprünglichen) Inhalt und nicht über den neuen Inhalt.
Problemumgehung:
Momentan wird das Problem wie folgt umgangen: Solche Dateien werden aus dem Dateisystem nach Schritt 1 gelöscht. Eine Liste solcher Dateien kann abgerufen werden:
- Im Dialogfenster für die Dateilöschung, wenn die Umsetzung nicht im Hintergrund ausgeführt wird.
- In der Liste der auf dem Dateisystem verfügbaren Dateien im Vergleich zu den zu dem Projekt gehörenden Dateien, wenn die Umsetzung für eine Ausführung im Hintergrund konfiguriert wurde.
- In der Liste leerer Artefakte im Zuordnungsmodell (falls vorhanden).
Die erneute Anwendung einer UML-zu-C#-Umsetzung mit ausgewählter Option für die Erstellung von Quelle-zu-Ziel-Beziehungen auf der Seite Allgemein für die Umsetzungskonfiguration nach dem Entfernen des Tags '@generated' aus dem C#-Code führt zur Generierung eines zusätzlichen URI-Tags im Code. Dieses Verhalten wurde nur bei Variablen beobachtet.
Der URI-Tag weist das folgende Format auf:
//@C#_transform [
// _URI=platform:/resource/UML%20project/Blank%20Model%20t1.emx#_cd19cKJhEdurjYIa4vhLGA//]
Durch das mehrere Male erneute Ausführen werden in der C#-Datei mehr URI-Tags erstellt.
Problemumgehung:
Zu diesem Problem ist derzeit keine Fehlerumgehung bekannt.
Wenn der Tag '@generated' für einen generierten Setter entfernt wird und sein Typ im Code vor der erneuten Ausführung der UML-zu-C#-Umsetzung geändert wird, wird ein zusätzlicher Setter generiert.
Dieses Problem umgehen Sie, indem Sie die Typänderung im Modell vornehmen.
Wenn eine UML-zu-C#-Umsetzung mit der Option zum Ersetzen von UML-Elementen ausgeführt wird, werden im UML-Modell enthaltene Aufzählungsliterale nicht ersetzt. Wenn eine Aufzählung E über die beiden Literale L1 und L2 verfügt und E im Paket p enthalten ist, wird die Aufzählung E nach der Ausführung der Umsetzung ordnungsgemäß durch einen Direktaufruf zu der in dem Code generierten C#-Aufzählung ersetzt; allerdings scheinen die Literale L1 und L2 nach der Umsetzung im Paket p enthalten zu sein.
Problemumgehung:
Zu diesem Problem ist derzeit keine Fehlerumgehung bekannt.
In einigen Fällen migriert das XDE-C#-Code-Modellimportprogramm (Datei -> Importieren -> Andere -> XDE .Net-Lösung) die Setter von C#-Indexierprogrammen nicht ordnungsgemäß. Möglicherweise kommt es nicht zu denselben Settern, die im Code vor dem Prozess vorhanden waren, wenn ein C#-Projekt in einer XDE .NET -Lösung durch Angabe des entsprechenden UML-Modells (EMX-Datei, die mit dem XDE-Basismodellimportprogramm importiert wurde) importiert und die UML-zu-C#-Umsetzung anschließend mit dem migrierten Modell als Quelle und dem migrierten Projekt als Ziel ausgeführt wird. In einigen Fällen wird der Setter gar nicht generiert, und in einigen Fällen wird der Setter mit einem zusätzlichen Parameter (mit Namenswert) erstellt; dies führt zu einem Kompilierungsfehler, da bei C# die Verwendung des Namenswerts für einen expliziten Parameter des Setters nicht möglich ist.
Problemumgehung:
Zu diesem Problem ist derzeit keine Fehlerumgehung bekannt.
Wenn eine UML-zu-C#-Umsetzung mit der Option zum Ersetzen von UML-Elementen auf der Seite Allgemein des Umsetzungskonfigurationseditors ausgeführt wird und ein Zuordnungsmodell verwendet wird, werden bei der Umsetzung die UML-Elemente im Quellenmodell nicht ersetzt, für die die Quellendateien in Ordnern generiert werden. Es werden nur die UML-Elemente durch Direktaufrufe zu den entsprechenden Elementen im Code ersetzt, für die der Code im Stammordner des C#-Zielprojekts generiert wird.
Problemumgehung:
Nach der ersten Ausführung der UML-zu-C#-Umsetzung werden das UML-Modell und das Zuordnungsmodell als genutzt markiert; führen Sie die Umsetzung noch einmal aus ,und nehmen Sie keine Änderungen an der Umsetzungskonfiguration oder am Zuordnungsmodell vor. Nun werden alle UML-Elemente im Modell durch Direktaufrufe ersetzt.
Wenn Rational XDE-Codemodelle importiert werden, werden auch alle so genannten "Assemblymodelle" (auch als "Systemmodelle" oder "Referenzmodelle" bezeichnet) importiert, auf die durch die Codemodelle verwiesen wird; außerdem wird auf sie in der Eclipse-basierten Umgebung verwiesen. Dies kann dazu führen, dass das Öffnen des importierten Codemodells viel Zeit in Anspruch nimmt.
Problemumgehung:
Löschen Sie die importierten Assemblymodelle, wenn Codemodelle erfolgreich importiert wurden. Diese Problemumgehung kann in folgenden Fällen verwendet werden: 1. Wenn Sie die UML-Elemente des importierten Codemodells durch direkte Codeverweise ersetzen und die Theorie der Operationen über die "gemischte Modellierung" verwenden möchten. 2. Wenn Sie lieber die UML-Elemente des Codemodells behalten und die Theorie der Operationen über die “wahre Roundtrip-Entwicklung (RTE)” verwenden möchten (iterative vorwärts und rückwärts gerichtete Umsetzungen und Abstimmung).Auswirkungen der Problemumgehung:
1. Durch das Löschen der Assemblymodelle lässt/lassen sich das/die importierte(n) Codemodell(e) viel schneller öffnen und bearbeiten.2. Das Produkt zeigt möglicherweise Warnungen oder “Fehler” über “fehlende” Referenzmodelle an, wenn das importierte Codemodell geöffnet wird. Diese Warnungen können ignoriert werden.
3. Das Produkt zeigt möglicherweise Warnungen oder “Fehler” über "fehlende" Referenzmodelle an, wenn für das importierte Codemodell eine Überprüfung ausgeführt wird. Diese Warnungen und Fehler können ignoriert werden.
Beispiel:
Angenommen, wir haben ein Visual Studio 2003 C#-Projekt mit dem Namen 'Project1' sowie das entsprechende XDE-Basismodell "Project1.mdx". Angenommen, dieses Modell bezieht sich auf die folgenden fünf Systemmodelle: System.mdx, mscorlib.mdx, System.Data.mdx, System.Web.mdx und System.Drawing.mdx.- Beginnen Sie mit der Migration des VS 2003-Projekts in VS 2005; verwenden Sie hierbei das Migrationsprogramm von VS 2005.
Importieren Sie das Projektmodell 'Project1.mdx' mit Hilfe der XDE-Modellimportfunktion (Datei > Importieren > Andere > Rational XDE-Modell). Importieren Sie alle Referenzmodelle (für das Importprogramm ist dies für die Sicherstellung der Modellintegrität während des Importprozesses erforderlich).- Dadurch werden sechs EMX-Dateien im Eclipse-Arbeitsbereich erstellt: “Project1.emx,” “System.emx mscorlib.emx,” “System.Data.emx,” “System.Web.emx,” und “System.Drawing.emx.”
- Importieren Sie als Nächstes die Visual Studio 2005-Lösung (Datei > Importieren > Andere > .NET-Lösung). Das traditionelle MDX-Modell wird in dieser Lösung ermittelt, und Sie werden dazu aufgefordert, den Namen des importierten Codemodells anzugeben, in diesem Fall “Project1.emx”. Zu diesem Zeitpunkt haben Sie auch die Möglichkeit, die UML-Elemente von Project1.emx durch Verweise auf den Code in der importierten Lösung zu ersetzen. Verwenden Sie diese Option bei “gemischter Modellierung”; verwenden Sie sich aber nicht für die “wahre RTE”.
- Der Importprozess ist nun beendet. Wenn Sie als Nächstes das Modell “Project1.emx” öffnen, versucht das UML-Framework, alle fünf Referenzmodelle zu laden und die Verweise von den Elementen in "Project1.emx" auf die Elemente in diesen Referenzmodellen aufzulösen. Dies ist der Grund für die Verzögerung beim Öffnen und Arbeiten mit dem importierten XDE-Modell.
- Um Auswirkungen auf die Leistung zu reduzieren, wählen Sie einfach alle fünf importierten Assemblymodelle aus, und löschen Sie sie. Wie bereits oben erwähnt, wirkt sich dies positiv auf die Leistung aus und führt dazu, dass Warnungen oder “Fehler” beim Öffnen oder Auswerten von “Project1.emx” auftreten; allerdings werden die Modellierungs- und Umsetzungsoperationen, die Sie möglicherweise mit “Project1.emx” durchführen möchten, nicht negativ beeinflusst.
Wenn eine C#-zu-UML-Umsetzung im Befehlszeilenmodus ausgeführt wird und alle anderen Optionen im Umsetzungskonfigurationseditor ausgewählt sind, schlägt die Umsetzung fehl. Dies geschieht insbesondere, wenn die neuen Änderungen für das Zielmodell stereotypisierte Elemente (z. B. <<CSharpStruct>>) enthalten, die im Befehlszeilenmodus zusammengeführt werden müssen. Dieses Problem wird in einem der nächsten Releases behoben.
Wenn eine C#-zu-UML-Umsetzung in einer Quellendatei mit überladenen Operatoren wie z. B. != oder == ausgeführt wird, dürfen, um diese Operatoren im Zielmodell bei einer daraufolgenden Ausführung der Umsetzung ohne Codeänderungen abzurufen, im Fusionsdialogfenster keine Änderungen angezeigt werden. Der Fusionsdialog zeigt jedoch Änderungen in Bezug auf die Umbenennung von Parametern falsch an.
Dieses Problem wird in einem der nächsten Releases behoben.
Bei C#-Umsetzungen muss eine Zuordnungsmodell zum Angeben lediglich der Dateisystemhierarchie verwendet werden, in der der Code organisiert werden soll. Die Umbenennung von Klassen, Schnittstellen usw. über das Zuordnungsmodell wird noch nicht unterstützt. Der Entwurf einer C#-Anwendung kann in 2 Perspektiven durchgeführt werden:
1. Entwurf für logisches System
2. Entwurf für physisches System (wird als Zuordnungsmodell angegeben)
Das logische Entwurfsmodell enthält normalerweise die unterschiedlichen Namensbereiche, die verschiedenen Typen sowie die Vererbungsbeziehung, Attribute, Funktionen usw.
Die physische Entwurfsperspektive, bei der ein Zuordnungsmodell verwendet wird, umfasst die Implementierungsinformationen für die C#-Umsetzung. Dies bedeutet, dass Sie steuern können, wie die Umsetzung die unterschiedlichen logischen Konstrukte in verschiedenen Dateien positionieren soll. Standardmäßig generiert die UML-zu-C#-Umsetzung ohne Zuordnungsmodell die einzelnen Typen, z. B. eine Klasse oder eine Schnittstelle, in einer Datei, deren Name mit dem Namen des Typs übereinstimmt; allerdings findet die Positionierung im Stammverzeichnis des Visual Studio-Projekts statt. Die Klasse "MyClass" wird beispielsweise in einer Datei mit dem Namen "MyClass.cs" ohne Zuordnungsmodell generiert. Allerdings sollte der Benutzer, wenn er möchte, dass der Code in einer Datei mit dem Namen "Test.cs" generiert wird, diesen Namen im Zuordnungsmodell über ein Artefakt angeben, das die Klasse "MyClass" enthält.
Das Zuordnungsmodell wird nur zur Angabe des Ordners oder der Dateihierarchie für die Codegenerierung verwendet. Mit einem Zuordnungsmodell kann keine Umbenennung durchgeführt werden.
Beachten Sie, dass es sich sowohl bei dem logischen Entwurf (Umsetzungsquellenmodell) als auch bei dem physischen Entwurf (Umsetzungszuordnungsmodell) nur um UML-Modelle handelt. Die einzigen Unterschiede sind folgende:
- UML-Pakete im logischen Quellenmodell stellen C#-Namensbereiche dar.
- UML-Pakete im Zuordnungsmodell stellen Ordner auf dem Dateisystem dar.
Wenn die UML-zu-C#-Umsetzung nach der Ausführung mit einer aktivierten Zuordnungsmodelloption und der ausgewählten Option für das Ersetzen von UML-Elementen rückgängig gemacht wird, weist das Zuordnungsmodell einen falschen Zustand auf. Wenn die UML-zu-C#-Umsetzung mit dem falschen Zuordnungsmodell erneut ausgeführt wird, werden die C#-Dateien an einer falschen Position generiert.
Problemumgehung:
Der Benutzer muss die Änderungen am Zuordnungsmodell manuell rückgängig machen, bevor die UML-zu-C#-Umsetzung erneut ausgeführt wird. Eine Möglichkeit, dies zu tun, besteht darin, das Zuordnungsmodell zu schließen und die Änderungen nicht zu speichern.
IBM Rational Software Support stellt technische Unterstützung bereit.
Kontaktinformationen und Richtlinien oder Referenzmaterial für den Erhalt der Unterstützung finden Sie in IBM Software Support Handbook.
Häufig gestellte Fragen (FAQs), Listen bekannter Probleme und Korrekturen sowie andere Unterstützungsinformationen finden Sie auf der Unterstützungsseite für IBM Rational Software Support.
Informationen zu Neuerungen von Rational-Softwareprodukten, Termine und weitere Informationen finden Sie auf der Website für IBM Rational Software.
Vor der ersten Kontaktaufnahme mit dem IBM Rational Software Support sollten Sie Hintergrundinformationen zusammenstellen, die Sie zur Beschreibung Ihres Problems benötigen. Gehen Sie bei der Beschreibung eines Problems gegenüber einem Berater der IBM Softwareunterstützung so konkret wie möglich vor und geben Sie alle relevanten Hintergrundinformationen weiter, damit Ihnen der Berater bei der Lösung des Problems so effektiv wie möglich helfen kann. Besorgen Sie sich vorab Antworten auf die folgenden Fragen, um Zeit zu sparen:
- Welche Softwareversionen wurden ausgeführt, als das Problem auftrat?
- Verfügen Sie über Protokolle, Traces oder Nachrichten zu diesem Problem?
- Können Sie das Problem reproduzieren? Wenn ja, welche Schritte führen Sie aus, um es zu reproduzieren?
- Gibt es eine Umgehung für dieses Problem? Wenn ja, sollten Sie darauf vorbereitet sein, die Ausweichlösung zur Umgehung dieses Problems zu beschreiben.
© Copyright IBM Corporation 2007. Alle Rechte vorbehalten.
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden. Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBM verwendet werden können. An Stelle der IBM Produkte, Programme oder Services können auch andere ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Produkten, Programmen und Services anderer Anbieter liegt beim Kunden.
Für in dieser Dokumentation beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieser Dokumentation ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):
IBM Director of Licensing
IBM Europe, Middle East & Africa
Tour Descartes
2, avenue Gambetta
92066 Paris La Defense
France
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in dieser Dokumentation werden in regelmäßigen Abständen aktualisiert. Die Änderungen werden in Überarbeitungen bzw. neuen Editionen der Veröffentlichung bekannt gegeben. IBM kann jederzeit ohne vorherige Ankündigung Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängig voneinander erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:
Intellectual Property Dept. for Rational Software
IBM Europe, Middle East & Africa
20 Maguire Road
Lexington, MA
02421-3112
USADie Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des in der Dokumentation aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der ICA-Lizenzbedingungen (IBM Customer Agreement), der internationalen Nutzungsbedingungen für Programmpakete oder einer äquivalenten Vereinbarung.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Die oben genannten Erklärungen bezüglich der Produktstrategien und Absichtserklärungen von IBM stellen die gegenwärtige Absicht von IBM dar, unterliegen Änderungen oder können zurückgenommen werden, und repräsentieren nur die Ziele von IBM.
Marken und Servicemarken
Die folgenden Ausdrücke sind in gewissen Ländern Marken oder eingetragene Marken von International Business Machines Corporation.
- developerWorks
- IBM
- Rational
Java und alle Java-basierten Marken sind in gewissen Ländern Marken von Sun Microsystems, Inc.
Microsoft, Windows und Windows NT sind in gewissen Ländern Marken oder eingetragene Marken von Microsoft Corporation.
Intel und Pentium sind in gewissen Ländern Marken oder eingetragene Marken der Intel Corporation oder ihrer Tochtergesellschaften.
UNIX ist in gewissen Ländern eine eingetragene Marke von The Open Group.
Linux ist in gewissen Ländern eine Marke von Linus Torvalds.
Andere Namen von Unternehmen, Produkten oder Services können Marken oder Servicemarken anderer Unternehmen sein.