ID document : GI11-7198-00
© Copyright International Business Machines Corporation 2007. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
La version la plus récente de ce document (en anglais) est disponible à l'adresse
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.IBM Rational Modeling Extension pour Microsoft .NET est une extension de modélisation C# et CTS destinée aux produits de modélisation UML Rational. Cette gamme d'outils de conception et de développement est basée sur l'infrastructure à source ouverte Eclipse. Le logiciel Modeling Extension pour Microsoft .NET comprend des plug-ins qui permettent aux architectes logiciels et aux développeurs orientés modèles de visualiser les applications C# et les types CTS, et de créer du code C# bien structuré en utilisant le langage UML 2.
Avec Rational Modeling Extension pour Microsoft .NET, vous pouvez :
- Importer des solutions .NET à partir de Microsoft Visual Studio 2005 pour en créer des images miroir au sein d'un projet Eclipse
- Visualiser des applications C#
- pour explorer leur architecture et en analyser les dépendances, à l'aide de diagrammes d'exploration ;
- pour documenter leur structure, à l'aide de diagrammes de classes ;
- pour documenter les interactions réelles (telles qu'elles sont implémentées) ou hypothétiques entre les classes, à l'aide de diagrammes de séquences ;
- pour dépeindre des types .NET à l'intérieur de diagrammes dans des modèles UML, dans le cadre de l'approche de "modélisation mixte".
- Transformer des modèles UML en code C#.
- Transformer les modifications apportées au code C# dans le modèle UML.
Pour les dernières informations sur la configuration requise pour l'installation, consultez la version actualisée de ce fichier readme à l'adresse : http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.
Vous pouvez aussi visualiser le guide d'installation de votre produit à partir du tableau de bord d'installation ainsi que dans le répertoire des documentations du CD du produit.
Rational Modeling Extension pour Microsoft .NET nécessite IBM Installation Manager version 1.0.0.2 ou ultérieure et IBM Rational Software Architect, IBM Rational Software Modeler ou IBM Rational Systems Developer version 7.0.0.1. L'installation du logiciel ne peut pas se poursuivre si les versions requises de ces produits ne sont pas installées au préalable.
Pour des informations sur l'installation de Rational Modeling Extension pour Microsoft .NET version 7.0, consultez les instructions d'installation disponibles sur le Web à l'adresse : http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/install_instruction/install.html.
Vous pouvez aussi visualiser le guide d'installation de votre produit à partir du tableau de bord d'installation ainsi que dans le répertoire des documentations du premier CD du produit.
L'extension de modélisation peut être installée sur la génération de disponibilité générale d'IBM Rational Software Architect v7.0.0.1, IBM Rational Software Modeler v7.0.0.1 ou IBM Rational Systems Developer v7.0.0.1. La procédure ci-dessous résume le processus d'installation. Pour des instructions plus détaillées, voir le guide d'installation d'IBM Rational Modeling Extension pour Microsoft .NET.
Pour installer le logiciel :
- Vérifiez que l'un des produits de modélisation UML Rational cités plus haut est installé.
- Dans l'outil IBM Installation Manager, sélectionnez le produit hôte avec lequel l'extension de modélisation sera installée.
L'extension de modélisation et le produit hôte partagent le même shell et utilisent la même instance d'Eclipse.- Suivez les instructions de l'assistant d'IBM Installation Manager pour installer l'extension de modélisation.
Les présentes notes contiennent des informations qui n'ont pas pu être incluses à temps dans la documentation finale du produit. Suivez les conseils donnés ici lorsque vous modélisez des applications .NET en utilisant le profil C#.
1. Visual Studio 2005 Standard ou Professional Edition doit être ouvert chaque fois que le produit Rational de modélisation UML dans lequel est installée l'extension est ouvert.
Remarque : le guide d'installation indique que "Visual Studio 2005" est un logiciel requis. Il convient de préciser qu'il s'agit de "Visual Studio 2005 Standard Edition ou Professional Edition". Les éditions Express ne sont pas prises en charge.
2. Utilisation de modèles précédemment importés de Rational XDE dans Rational Software Architect version 6.x
Si vous avez des modèles qui ont été importés de Rational XDE dans Rational Software Architect version 6.x et que vous les avez fait migrer (ou que vous comptez les faire migrer) vers Rational version 7.0.0.1, et si vous utilisez également l'extension de modélisation, la fonction d'importation de modèles Rational XDE de Rational Software Architect doit être également installée.
3. Lorsque vous nommez des packages dans le modèle, n'utilisez pas de ‘.’ (point) dans leur nom. Par exemple, si vous avez besoin d'imbriquer le package ‘xtools’ dans le package ‘ibm’ et ce dernier dans le package ‘com’, au lieu de créer un package unique appelé “com.ibm.xtools”, utilisez une structure de packages hiérarchique et créez un package “com” dans lequel vous imbriquerez le package “ibm”, dans lequel vous imbriquerez le package “xtools”. Cette notation possède toujours une représentation unique et vous aidera à réduire le nombre de fausses modifications de fusion ("fuse") lors de la transformation de code en modèle.
4. N'appliquez des stéréotypes C# que lorsque vous avez besoin de définir des valeurs spécifiques à C# par l'intermédiaire des propriétés de stéréotypes. Si le même code est généré sans application du stéréotype, la transformation C# vers UML considère qu'il n'y a pas eu de stéréotype utilisé durant la précédente transformation UML vers C#, et la fenêtre de réconciliation s'ouvre pour présenter une différence suggérant que le stéréotype soit supprimé du modèle UML.
5. Dans sa version actuelle, le profil C# ne définit pas de contraintes, si bien que les combinaisons non valides de stéréotypes appliqués ne sont pas détectées. Evitez donc d'utiliser les stéréotypes de profil de façon incorrecte. Par exemple, appliquer simultanément <<CSharpClass>> et <<CSharpInterface>> n'est pas valide et conduira à un comportement de transformation imprévisible.
6. Lors de la modélisation de types partiels, utilisez un type vide comme type partiel sur lequel chaque partie est indiquée comme dépendante. Incluez le type partiel vide modélisé (la source) et les types partiels définis (avec les relations de dépendances à la source) dans un même package du modèle. De cette façon, toutes les parties du type partiel sont définies dans un seul package du modèle. Dans ce cas, c'est le nom de la source qui sera utilisé comme nom du type, et non le nom des autres parties. En utilisant un modèle de mappage, chaque partie partielle peut être affectée à un fichier différent. Lors de la transformation du code en modèle, le nom choisi par l'utilisateur pour chacune des parties n'est pas connu, ce qui fait que la transformation crée des noms de la forme <nom-type>_<nom-fichier>, qui apparaissent comme des différences dans la boîte de dialogue de fusion.
7. En C#, il n'est possible d'utiliser des types génériques que si les valeurs des paramètres de type sont spécifiées ; cela signifie que pour construire un nouveau type pour un type générique, il convient de lier ses paramètres de type. Ainsi, une classe List avec le paramètre T peut être utilisée sous la forme List<String> etc. En langage UML, les types complexes de ce genre sont représentés sous forme de liaisons de modèles, et leurs noms ne sont pas utilisés lors de la transformation du code en UML pour générer le modèle temporaire. Ces types complexes apparaissent donc comme des noms de types anonymes et figurent comme des différences dans la boîte de dialogue de fusion : vous devrez les mapper vers la liaison de modèle réelle dans le modèle cible.
Les opérateurs surchargés sont modélisés en tant qu'opérations. Par exemple, supposons que vous vouliez surcharger les deux opérateurs suivants dans le contexte de la classe C1 et que vous vouliez modéliser cette tâche avec Modeling Extension pour Microsoft .NET.
Equal (==)
Not equal (!=)Les étapes suivantes décrivent comment la surcharge des opérateurs peut être modélisée avec cet exemple.
Prérequis :
Un modèle UML doit avoir été créé ou ouvert.Pour modéliser les opérateurs surchargés :
- Créez une nouvelle classe dans le modèle UML, appelée C1.
- Ajoutez une nouvelle opération à la classe C1 et nommez-la opérateur !=. Cet opérateur contiendra l'implémentation de l'opérateur surchargé !=.
- Définissez l'opérateur comme suit.
a. Spécifiez Public pour la visibilité de l'opération nouvellement créée.
b. Spécifiez Static pour les qualificateurs de l'opération nouvellement créée.
c. Définissez le type de retour de l'opération nouvellement créée à <Type primitif>bool.
d. Ajoutez deux paramètres du type C1 à l'opération nouvellement créée et nommez-les c1 et c2.- Ajoutez une autre opération à la classe C1 et nommez-la opérateur ==. Cet opérateur contiendra l'implémentation de l'opérateur surchargé ==.
- Définissez l'opérateur comme à l'étape 3.
La modélisation des opérateurs surchargés != et == dans le contexte de la classe C1 est terminée.
Les présentes notes contiennent des informations spécifiques à cette édition, telles que ses limitations et les problèmes recensés, qui n'ont pas pu être incluses à temps dans la documentation finale du produit.
L'extension de modélisation n'avertit pas l'utilisateur lorsque le code importé n'a pas été compilé correctement. Si le projet C# importé contient du code comportant des erreurs de syntaxe, l'indicateur de l'extension de modélisation qui signale les erreurs ne sera pas affiché dans l'Explorateur de projets ou les diagrammes de visualisation.
Solution : Assurez-vous que la compilation du code C# réussit dans Visual Studio .NET avant de lui appliquer toute transformation et avant de l'importer dans Modeling Extension pour Microsoft .NET.
- Modeling Extension pour Microsoft .NET ne reconnaît que la première instance ouverte de Visual Studio 2005 et ne communique qu'avec elle. Pour cette raison, n'exécutez qu'une seule instance de Visual Studio à la fois sur la machine où vous utilisez Modeling Extension pour Microsoft .NET.
- Ne fermez ni n'ouvrez jamais une autre solution (autre que celle importée) dans Visual Studio lorsque Modeling Extension pour Microsoft .NET est en cours de fonctionnement.
- Gardez toujours une instance de Visual Studio 2005 ouverte ; Modeling Extension pour Microsoft .NET ne reconnaîtra que la première instance de Visual Studio 2005 et ne communiquera qu'avec elle.
- Lorsqu'une solution est importée dans Modeling Extension pour Microsoft .NET, un projet Eclipse est créé dans l'espace de travail Eclipse pour chaque projet C# qu'elle contient. Chaque projet ainsi créé dans Eclipse porte le même nom que le projet C# de la solution Visual Studio 2005. Voici les points importants à noter à propos de ces projets :
- Les projets créés dans Eclipse contiendront des liens vers les fichiers C# et les assemblys .NET utilisés par les projets C# correspondants dans la solution Visual Studio 2005. Ces liens sont le seul moyen par lequel Modeling Extension pour Microsoft .NET peut extraire, mettre à jour et afficher des informations concernant les projets Visual Studio 2005 et leur contenu dans Eclipse. En réalité, ils jouent le rôle de vue des projets C# dans Eclipse.
- Evitez d'utiliser les mécanismes Eclipse (excepté les transformations UML-C#) pour modifier les projets importés. L'utilisation de ces mécanismes pour renommer des projets ou modifier leur contenu peut conduire à des résultats imprévisibles. Evitez en particulier de créer ou d'ajouter des modèles UML (.emx) ou des fichiers diagrammes (.dnx) dans les projets. Créez et utilisez pour cela des projets distincts (tels que des projets UML) dans Eclipse. Il faut en particulier veiller à éviter que des fichiers diagrammes (.dnx) ne soient créés dans les projets importés, car lorsque de nouveaux diagrammes sont créés, l'infrastructure de visualisation les place, par défaut, dans les projets où résident les éléments visualisés.
- Vous pouvez fermer et rouvrir sans risque les projets importés. Vous pouvez aussi les supprimer, mais ne supprimez pas leur contenu sous-jacent (si vous souhaitez réellement supprimer un projet Visual Studio et son contenu, faites-le dans Visual Studio).
- Lorsque vous avez importé une solution Visual Studio 2005 dans Eclipse, évitez de renommer les projets C# dans Visual Studio 2005. Si vous devez renommer un projet, procédez comme suit :
- Supprimez le projet Eclipse (importé) correspondant, mais pas le contenu sous-jacent.
- Renommez le projet dans Visual Studio.
- Réimportez la solution Visual Studio (Modeling Extension pour Microsoft .NET peut importer la solution de façon incrémentielle. Cette capacité est également utile pour l'importation de projets C# nouvellement ajoutés à la solution Visual Studio 2005.)
- Avant d'entreprendre toute action dans Modeling Extension pour Microsoft .NET, assurez-vous que les projets C# ne contiennent pas d'erreur de syntaxe et qu'ils peuvent être compilés correctement dans Visual Studio 2005. Modeling Extension pour Microsoft .NET utilise les API Code Model de Visual Studio pour analyser la syntaxe des fichiers C#. Ces API renvoient des résultats incorrects et des valeurs NULL lorsque les fichiers C# contiennent des erreurs. Par exemple, si, après avoir modifié un fichier C# dans Visual Studio, vous actualisez son projet dans Eclipse et constatez que la branche du fichier ne peut pas être développée dans l'Explorateur de projets, cela signifie peut-être que des erreurs de syntaxe C# ont été introduites par la modification.
Dans ce cas, la méthode conseillée consiste à retourner dans Visual Studio 2005 pour corriger toutes les erreurs de syntaxe et recompiler (ou regénérer) la solution, puis à actualiser le projet importé dans Eclipse pour que les modifications soient prises en compte. Il est particulièrement important que les solutions Visual Studio soient dans un état propre et généré avant l'application de toute transformation.- Modeling Extension pour Microsoft .NET utilise un mécanisme COM pour se synchroniser avec Visual Studio 2005. Les appels COM peuvent échouer ou être rejetés si Visual Studio 2005 est indisponible. Par conséquent, ne travaillez pas dans Visual Studio 2005 ou ne le rendez pas actif lorsque vous effectuez les opérations suivantes dans Modeling Extension pour Microsoft .NET :
- Importer des solutions .NET
- Actualiser des projets
- Développer les projets ou fichiers importés dans l'Explorateur de projets (par exemple, développer la vue arborescente)
- Démarrer Modeling Extension pour Microsoft .NET dans un espace de travail où une solution Visual Studio 2005 a été précédemment importée
- Composer un diagramme de visualisation .NET
- Exécuter une transformation UML vers C# ou C# vers UML
- Si vous ne comptez pas examiner le contenu des types définis dans les assemblys .NET (par exemple, pour savoir quels champs ou opérations ils contiennent), activez l'option "Lors de l'interprétation des assemblys .Net, obtenir uniquement les "types"" lors de l'importation de la solution Visual Studio 2005 dans votre espace de travail Eclipse. Cette option figure sur la première page de l'assistant Importation de solution .Net. Son activation permet d'accélérer l'importation de la solution et la visualisation des types C# et .NET.
- Dans Visual Studio 2005, activez toujours l'option de chargement automatique des modifications. Pour ce faire, cochez la case “Charger automatiquement les modifications" qui figure sur la page Environnement -> Documents de la fenêtre Options. Pour ouvrir cette dernière, sélectionnez “Outils -> Options -> Environnement -> Documents -> Détecter quand le fichier est modifié en dehors de l'environnement -> Charger automatiquement les modifications, si elles ont été enregistrées”.
- Vous pouvez modifier l'encodage des projets C# dans Eclipse en sélectionnant l'option Propriétés dans le menu contextuel des projets importés. Notez que cet encodage sera plus long que l'encodage normal car les projets Visual Studio sont normalement volumineux.
Lorsque vous utilisez une classe/struct/interface imbriquée pour définir le type d'un élément dans une classe/struct/interface externe, le nom du type inclut toujours le nom des types externes, bien que le type et l'élément soient définis dans la même classe. Il n'existe pas de solution connue à ce jour. Ce problème sera traité dans une future version.
Par exemple, le modèle suivant :
- ClasseExterne
+ ClasseInterne
+ attribut1 : ClasseInterneproduira la déclaration suivante dans le code généré pour ClasseInterne, à l'intérieur du fichier ClasseExterne.cs :
private ClasseExterne.ClasseInterne attribut1;
La transformation directe des caractères Unicode présents dans un modèle UML (par exemple, les noms de classe, la documentation, etc.) n'est pas prise en charge dans cette édition. Tous les caractères Unicode seront remplacés par des '?' dans les fichiers C# générés correspondants.
Lorsque Modeling Extension pour Microsoft .NET est installé avec IBM Rational Software Modeler, la visite guidée (viewlet) faisant la démonstration des fonctions de Modeling Extension pour Microsoft .NET n'est pas disponible sur la page Bienvenue (vous êtes normalement supposé pouvoir y accéder en cliquant sur Généralités > Différentes approches de modélisation > En savoir plus sur les transformations de modèle). Cette visite est cependant disponible dans la galerie de tutoriels.
Pour visionner la visite guidée dans Rational Software Modeler, cliquez sur Aide > Tutoriels, développez l'entrée Visites guidées, puis sélectionnez Transformer des modèles UML en code C#. Cliquez sur Démarrer la visite pour lancer le viewlet.
Dans certains cas, lorsque vous réexécutez une transformation UML vers C# en choisissant les options de mappage et de création des relations entre source et cible, le code généré est altéré. Par exemple, il peut manquer des caractères "/" dans les commentaires. Le code peut aussi comporter d'autres erreurs.
Cela se produit lorsque la relation aux manifestes passe d'un artefact à un autre dans le modèle de mappage, de sorte que les utilisateurs puissent combiner le code dans un même fichier .cs ou le séparer dans deux fichiers.
Ce défaut sera corrigé dans une future édition.
A la première exécution d'une transformation C# vers UML sur un modèle de code XDE importé, la boîte de dialogue de réconciliation présente de nombreuses différences ayant trait aux stéréotypes. Ceci parce que les stéréotypes liés à XDE dans le modèle importé ne sont pas reconnus par la transformation C# vers UML. Ce défaut sera corrigé dans une future édition.
Solution :
Effectuez une transformation de nettoyage ("cleanup") immédiatement après avoir importé le modèle de code XDE (et avant d'entreprendre toute modification dans le modèle ou dans le code). Exécutez ensuite la transformation C# vers UML. Lorsque la boîte de dialogue de réconciliation apparaît, acceptez tous les changements suggérés en faveur du modèle temporaire (celui qui est présenté dans le volet gauche). Les stéréotypes seront ainsi supprimés du modèle stocké et les exécutions suivantes de la transformation C# vers UML ne signaleront plus les différences.
Soit un modèle contenant des propriétés UML stéréotypées telles que <<CSharpProperty>>, <<CSharpField>>, etc., dont le type n'est pas défini et dont le code source spécifie les types issus des assemblys comme des types de données (datatypes) pour ces éléments. Si une transformation C# vers UML est exécutée sur un tel code et un tel modèle cible, la fusion montre correctement le type de données (un vizref UML) qui sera défini pour chaque élément, mais une fois l'opération terminée, le type de données est manquant (null) pour cet élément. Ce défaut est connu et sera corrigé dans une future édition.
Si un modèle contient un symbole # dans son nom de fichier et qu'il est spécifié comme cible d'une transformation C# vers UML, la boîte de dialogue de fusion n'affiche pas les deux volets (modèle temporaire et modèle cible) pour la fusion des différences. Ce défaut sera corrigé dans une future édition.
Si un modèle XDE importé est désigné comme cible d'une transformation C# vers UML et si Modèle de mappage est spécifié dans la configuration de la transformation, cette dernière échoue avec une exception de pointeur null (NullPointerException). Ce problème se manifeste uniquement dans le cas des modèles XDE importés avec modèle de mappage.
Solution :
Supprimez le package <<Artifacts>> du modèle importé et exécutez la transformation. Cette suppression n'entraîne pas de perte d'informations, car le modèle de mappage contient les données relatives aux différents fichiers, etc. Ce défaut sera corrigé dans une future édition.
Si un modèle cible est créé à l'aide du bouton Créer un nouveau conteneur cible de l'éditeur de configuration de transformation, il arrive que la mise en évidence se place sur le modèle nouvellement créé et que le nouveau modèle ne soit pas sélectionné dans le volet cible (où C# vers UML est la transformation directe).
Solution :
Basculez manuellement vers l'éditeur de configuration et sélectionnez le modèle cible. Ce défaut est connu et sera corrigé dans une future édition.
Si une transformation UML vers C# est exécutée avec un modèle de mappage modifié et qu'elle conduit à la suppression d'un fichier, et si l'utilisateur confirme la suppression du fichier dans la boîte de dialogue Suppression de fichier, ce fichier n'est pas véritablement supprimé. Il est juste retiré du projet, afin de préserver le contenu.
Plus tard, si la transformation UML vers C# est à nouveau exécutée et qu'elle conduit à la recréation du fichier qui a été supprimé (retiré du projet) à l'étape précédente, le fichier recréé contient les anciennes données (originales) à la place des nouvelles.
Solution :
La solution actuellement proposée pour pallier ce défaut est d'identifier les fichiers concernés par cette situation et de les supprimer du système de fichiers après l'étape 1. Vous pouvez obtenir la liste de ces fichiers de différentes manières :
- dans la boîte de dialogue Suppression de fichier, si la transformation n'est pas exécutée en mode silencieux ;
- en comparant la liste des fichiers dans le système de fichiers à celle des fichiers appartenant au projet, si la transformation est configurée pour s'exécuter en mode silencieux ;
- en consultant la liste des artefacts vides dans le modèle de mappage (le cas échéant).
Si, après avoir supprimé la balise @generated du code C#, vous réappliquez une transformation UML vers C# en sélectionnant l'option Créer des relations source/cible sur la page Attributs communs de l'éditeur de configuration de transformation, une balise URI supplémentaire est générée dans le nouveau code. Ce comportement a été observé uniquement avec les variables.
La balise URI est de la forme :
//@C#_transform [
// _URI=platform:/resource/UML%20project/Blank%20Model%20t1.emx#_cd19cKJhEdurjYIa4vhLGA//]
Le fait de réappliquer ensuite la transformation génère à chaque fois une autre balise URI dans le fichier C#.
Solution :
Il n'existe actuellement aucune solution à ce problème.
Si la balise @generated d'une méthode set générée est supprimée et que le type de l'attribut correspondant est changé dans le code, puis que la transformation UML vers C# est réexécutée, une méthode set en trop est générée.
La solution consiste à effectuer le changement de type dans le modèle.
Lorsqu'une transformation UML vers C# est exécutée et que l'option Remplacer les éléments UML est sélectionnée, les littéraux d'énumération présents dans le modèle UML ne sont pas remplacés. Si une énumération E a deux littéraux, L1 et L2, et que E est contenue par le package p, après l'exécution de la transformation, E est correctement remplacée par un raccourci à l'énumération C# générée dans le code, mais les littéraux L1 et L2 semblent être contenus dans le package p.
Solution :
Il n'existe actuellement aucune solution à ce problème.
Dans certains cas, l'importateur de modèle de code C# XDE (Fichier -> Importer -> Autre -> Solution .Net XDE) ne fait pas migrer correctement les méthodes set des indexeurs C#. Lorsque vous importez un projet C# contenu dans une solution .NET XDE en spécifiant le modèle UML correspondant (fichier .emx ; importé via l'importateur de modèle de base XDE) et que vous exécutez la transformation UML vers C# en spécifiant le modèle migré comme source et le projet migré comme cible, les méthodes set résultantes ne sont parfois pas les mêmes que celles qui existaient dans le code avant l'importation. Dans certains cas, elles ne sont même pas générées. Dans d'autres, elles sont générées, mais avec un paramètre supplémentaire (avec name value) qui provoque une erreur de compilation, car C# n'autorise pas l'utilisation du format name value pour un paramètre explicite d'une méthode set.
Solution :
Il n'existe actuellement aucune solution à ce problème.
Lorsqu'une transformation UML vers C# est configurée avec l'option Remplacer les éléments UML (sur la page Attributs communs de l'éditeur de configuration de transformation) et qu'un modèle de mappage est utilisé, l'exécution de cette transformation ne remplace pas les éléments UML dans le modèle source pour lequel les fichiers source sont générés dans les dossiers. Seuls les éléments UML pour lesquels le code est généré sous le dossier racine du projet C# cible sont remplacés par des raccourcis aux éléments correspondants dans le code.
Solution :
Après la première exécution de la transformation UML vers C#, le modèle UML et le modèle de mappage sont marqués comme modifiés. Exécutez à nouveau la transformation sans apporter de modification à sa configuration ni au modèle de mappage. Dès lors, tous les éléments UML dans le modèle seront remplacés par des raccourcis.
Lorsque vous importez des modèles de code Rational XDE, les éventuels "modèles d'assemblage" (également appelés "modèles système" ou "modèles de référence") auxquels ils font référence sont également importés et référencés dans l'environnement Eclipse. L'ouverture de ces modèles de code importés peut donc prendre du temps.
Solution :
Une fois les modèles de code correctement importés, supprimez les modèles d'assemblage qui ont été importés simultanément. Cette solution est valable dans tous les cas, que vous choisissiez de remplacer les éléments UML du modèle de code importé par des références directes au code et d'utiliser l'approche de "modélisation mixte" ou que vous choisissiez au contraire de préserver les éléments UML du modèle de code et d'appliquer l'approche d'“ingénierie aller-retour” (itérations successives de transformations directes et inverses avec réconciliation).Effets de cette solution :
1. La suppression des modèles d'assemblage rendra l'ouverture et l'édition des modèles de code importés beaucoup plus rapides.2. A l'ouverture du modèle de code importé, il est possible que le produit affiche des avertissements ou des “erreurs” à propos des modèles référencés “manquants”. Vous pouvez les ignorer sans risque.
3. Lors de la validation du modèle de code importé, il est possible que le produit affiche des avertissements ou des “erreurs” à propos des modèles référencés "manquants". Vous pouvez les ignorer sans risque.
Exemple :
Vous avez un projet C# appelé Projet1 qui a été créé dans Visual Studio 2003, avec son modèle de base XDE correspondant, "Projet1.mdx". Ce modèle contient des références aux cinq modèles système suivants : System.mdx, mscorlib.mdx, System.Data.mdx, System.Web.mdx et System.Drawing.mdx.- Commencez par faire migrer le projet VS 2003 vers VS 2005 à l'aide de l'utilitaire de migration correspondant.
Importez le modèle du projet Projet1.mdx en utilisant l'importateur de modèle XDE (Fichier > Importer > Autre > Modèle Rational XDE). Vous choisissez d'importer également tous les modèles auxquels il fait référence (cette opération est nécessaire pour garantir l'intégrité du modèle durant le processus d'importation).- Le résultat est la création de six fichiers .emx dans l'espace de travail Eclipse : “Projet1.emx”, “System.emx”, “mscorlib.emx”, “System.Data.emx”, “System.Web.emx” et “System.Drawing.emx”.
- Importez ensuite la solution Visual Studio 2005 (Fichier > Importer > Autre > Solution .NET). Le modèle .mdx existant est alors détecté dans cette solution et le produit vous demande de fournir le nom du modèle de code importé (dans notre cas, “Projet1.emx”). A cette occasion, vous avez la possibilité d'opter pour le remplacement des éléments UML de Projet1.emx par des références directes au code dans la solution importée. Utilisez cette option si vous souhaitez mettre en pratique l'approche de “modélisation mixte” ; ne l'utilisez pas si vous souhaitez au contraire appliquer l'approche d'“ingénierie aller-retour” (RTE).
- Le processus d'importation est maintenant terminé. Lorsque vous ouvrez ensuite le modèle “Projet1.emx”, l'infrastructure UML tente de charger les cinq modèles référencés et de résoudre les références entre les éléments du modèle "Projet1.emx" et ceux des modèles référencés. C'est la raison pour laquelle l'ouverture du modèle XDE importé prend si longtemps.
- Pour remédier à ce problème de performances, il vous suffit de sélectionner et de supprimer chacun des cinq modèles d'assemblage importés. Comme indiqué plus haut, des messages d'avertissement ou d'“erreur” s'afficheront à l'ouverture et à la validation du modèle “Projet1.emx”, mais ils n'auront aucun impact négatif sur les opérations de modélisation et de transformation que vous pourrez être amené à effectuer avec ce modèle.
Si une transformation C# vers UML est exécutée en mode silencieux et que toutes les autres options sont sélectionnées dans sa configuration (via l'éditeur correspondant), la transformation échoue. Cela arrive plus particulièrement lorsque de nouveaux changements incorporés dans le modèle cible contiennent des éléments stéréotypés (par exemple, <<CSharpStruct>>) qui doivent être fusionnés en mode silencieux. Ce défaut sera corrigé dans une future édition.
Si une transformation C# vers UML est exécutée sur un fichier source contenant des opérateurs surchargés tels que != ou == pour obtenir ces opérateurs dans le modèle cible, à l'exécution suivante de la transformation, si aucune modification n'a été apportée au code, la boîte de dialogue de fusion ne devrait théoriquement présenter aucun changement. Cependant, elle affiche à tort des changements ayant trait à la nécessité de renommer les paramètres.
Ce défaut sera corrigé dans une future édition.
Dans le cas des transformations C#, un modèle de mappage doit être utilisé uniquement pour spécifier comment le code doit être organisé vis-à-vis de la hiérarchie du système de fichiers. Le renommage des classes, des interfaces, etc. par le biais du modèle de mappage n'est pas encore pris en charge. La conception d'une application C# peut se faire suivant deux perspectives :
1. Conception du système logique
2 Conception du système physique (spécifiée comme modèle de mappage)
Le modèle de conception logique contient normalement les différents espaces de noms, les différents types et la relation d'héritage, les attributs, les fonctions, etc.
La perspective de conception physique utilisant un modèle de mappage inclut les informations de déploiement destinées à la transformation C#. Cela signifie que vous pouvez décider de la manière dont la transformation doit placer les diverses constructions logiques dans différents fichiers. Par défaut, sans modèle de mappage, la transformation UML vers C# génère chaque type (par exemple, une classe ou une interface) dans un fichier dont le nom est identique à celui du type, mais qui est placé dans le dossier racine du projet Visual Studio. Par exemple, en l'absence de modèle de mappage, "MaClasse" sera générée dans un fichier appelé "MaClasse.cs". Cependant, si l'utilisateur souhaite que le code soit généré dans un fichier appelé "Test.cs", il doit le spécifier dans le modèle de mappage au moyen d'un artefact jouant le rôle de manifeste pour la classe "MaClasse".
Le modèle de mappage sert uniquement à spécifier le dossier ou la hiérarchie de fichiers à utiliser pour générer le code. Vous ne pouvez pas l'utiliser pour renommer des éléments.
Notez que la conception logique (modèle source de la transformation) et la conception physique (modèle de mappage de la transformation) ne sont que des modèles UML. Les seules différences sont les suivantes :
- Dans le modèle source (conception logique), les packages UML représentent des espaces de noms C#.
- Dans le modèle de mappage (conception physique), les packages UML représentent des dossiers du système de fichiers.
Si une transformation UML vers C# est annulée après avoir été exécutée avec l'option Modèle de mappage activée et la case Remplacer les éléments UML cochée, le modèle de mappage n'est plus dans un état correct. Si vous exécutez à nouveau la transformation UML vers C# avec le modèle de mappage endommagé, les fichiers C# sont générés à un emplacement incorrect.
Solution :
Annulez manuellement les modifications apportées au modèle de mappage avant d'exécuter à nouveau la transformation UML vers C#. Pour cela, vous pouvez fermer le modèle de mappage et choisir de ne pas enregistrer les modifications qu'il a subies.
Le centre de support IBM Rational vous fournit une assistance technique.
Pour savoir comment contacter le support technique et connaître les informations de référence dont vous aurez besoin en cas de demande d'assistance, lisez le manuel IBM Software Support Handbook (en anglais).
Pour consulter les questions les plus fréquentes, la liste des problèmes identifiés et des correctifs disponibles et toute autre information de support, visitez le site Web IBM Rational Software Support (en anglais).
Pour connaître les nouveautés, les événements et autres informations en rapport avec les produits Rational, visitez le site Web IBM Rational Software (en anglais).
Avant de contacter le support IBM Rational, rassemblez les informations dont vous aurez besoin pour décrire votre problème. Lorsque vous décrivez un problème à un technicien du support IBM, soyez aussi précis que possible et fournissez-lui toutes les informations pertinentes afin qu'il puisse résoudre le problème efficacement. Pour gagner du temps, préparez vos réponses aux questions suivantes :
- Quelles versions de logiciels exécutiez-vous lorsque l'incident s'est produit ?
- Disposez-vous des journaux, des enregistrements de trace et des messages relatifs au problème ?
- Pouvez-vous reproduire l'incident ? Dans l'affirmative, quelles sont les étapes suivies pour reproduire l'incident ?
- Avez-vous trouvé une solution palliative au problème ? Si oui, soyez prêt à la décrire.
© Copyright IBM Corporation 2007. All Rights Reserved.
Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits décrits dans le présent document. La remise de cette documentation ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez recevoir des informations concernant l'acquisition de licences, veuillez en faire la demande par écrit à l'adresse suivante :
IBM EMEA Director of Licensing
IBM Europe Middle-East Africa
Tour Descartes La Défense 5
2, avenue Gambetta
92066 Paris-La Défense CEDEX France
Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues par écrit à l'adresse suivante :IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, JapanLe paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans lequel il serait contraire aux lois locales : LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT". IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Des modifications sont régulièrement apportées à ces informations ; ces modifications seront intégrées dans les nouvelles éditions de la publication. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels décrits dans ce document.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Intellectual Property Dept. for Rational Software
IBM Corporation
20 Maguire Road
Lexington, MA
02421-3112
USACes informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux dispositions de l'ICA, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Toute instruction relative aux intentions d'IBM pour ses opérations à venir est susceptible d'être modifiée ou annulée sans préavis, et doit être considérée uniquement comme un objectif.
Marques et logos
Les termes qui suivent sont des marques d'International Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays :
- developerWorks
- IBM
- Rational
Java ainsi que tous les logos et toutes les marques incluant Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
Microsoft, Windows et Windows NT sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.
Intel et Pentium sont des marques d'Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans certains autres pays.
Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.
Les autres noms de sociétés, de produits et de services peuvent appartenir à des tiers.