La transformation d'UML vers CORBA transforme en IDL (Interface Definition Language) CORBA (Common Object Request Broker Architecture) les éléments de modèles UML (Unified Modeling Language) de version 2.0. Vous pouvez utiliser la transformation pour donner des valeurs de départ à un projet CORBA à partir de spécifications UML 2.0. La transformation fournit également un profil léger, qui est à votre disposition pour la modélisation et la génération de la plupart des éléments CORBA.
Pour pouvoir utiliser la transformation d'UML vers CORBA, vous devez être à l'aise avec la création et l'édition de modèles et de projets UML 2.0. La procédure qui suit illustre l'utilisation la plus basique de la transformation en CORBA.
Pour transformer en CORBA un modèle UML :
1. Vous devez vous trouver dans la perspective de modélisation.
2. Dans la vue Explorateur de modèle, créez un composant UML, que vous nommerez "Composant1", et, à l'intérieur de ce composant, créez une interface, que vous appellerez "Interface1".
3. Cliquez avec le bouton droit de la souris sur le composant, puis cliquez sur Transformer > Exécuter transformation > UML vers CORBA.
4. Dans la fenêtre Exécution de la transformation, cliquez sur Créer le conteneur de la cible.
5. Dans la fenêtre Nouveau projet, indiquez Exemple comme nom du projet et cliquez sur Fin.
Le nouveau projet contient un fichier IDL appelé "Composant1.idl", pour lequel une interface est définie sous le nom d'Interface1.
La transformation peut également assurer plusieurs autres fonctions plus complexes telles la substitution de noms sans modification du modèle source, la validation du modèle UML pour les incidents de transformation potentiels, etc.
Vous avez la possibilité de spécifier comme source de chacune des applications de la transformation un modèle UML, un composant, un package contenant des composants ou une combinaison de tous ces éléments. La transformation génère un fichier IDL par composant UML présent dans la hiérarchie de la source indiquée. Chaque fichier IDL contient uniquement le code des éléments possédés par le composant UML correspondant. La transformation ignore les éléments qui n'appartiennent pas à un composant UML. Si vous spécifiez tout autre élément comme source de la transformation, celle-ci échoue au cours de la validation.
Lors de l'application du profil CORBA, vous pouvez déterminer les composants UML de votre modèle pour lesquels la transformation doit générer du code. Il vous suffit pour cela de donner à leur propriété generateCode la valeur true ou false. Lors de la génération du code, la transformation ignore les composants dont la propriété a la valeur false.
La cible de chacune des applications de la transformation est une simple ressource de projet Eclipse. Le projet contient le ou les fichiers IDL qui sont considérés comme des fichiers de ressources dans l'espace de travail Eclipse.
La modélisation des types CORBA suivants ne nécessite pas le recours à un profil :
Un profil facultatif comporte des stéréotypes permettant de modéliser des types CORBA plus spécifiques, tels que :
Le profil de la transformation vers CORBA définit des contraintes sur des stéréotypes. Pour évaluer ces contraintes et signaler les éventuelles erreurs du modèle source, vous pouvez utiliser la commande "Exécuter validation". La transformation vers CORBA procède également à une validation supplémentaire sur la partie du modèle à laquelle elle s'applique.
Un modèle de mappage vous permet de renommer les éléments modélisés dans le code généré. Vous ne pouvez renommer les éléments UML autres que des composants qu'avec des identifiants simples. Pour renommer les composants UML, vous pouvez utiliser soit un identifiant simple, soit un chemin partiel valide relatif au conteneur cible où est généré le fichier IDL. Le chemin doit se terminer par le nom du fichier IDL. Par exemple, si vous renommez répA\A le composant A, la transformation générera A.idl dans le répertoire répA, au lieu de le placer au sommet du conteneur cible.
Le tableau suivant indique les correspondances entre les éléments de modèle UML 2.0 et les éléments IDL CORBA établies par la transformation.
Élément UML 2.0 |
Élément IDL CORBA |
Modèle |
Rien |
Composant |
Fichier IDL |
Types primitifs |
Types de base |
Types natifs |
|
Package |
Module (si le package se trouve dans un composant) |
Ignoré (si le package ne se trouve pas dans un composant) |
|
Interface |
Interface |
Attribut ou association |
Attribut |
Opération |
Opération IDL |
Paramètre |
Paramètre d'opération IDL |
Énumération |
Énumération |
Classe <<CORBAValue>> |
Type de valeur |
Type de valeur personnalisée |
|
Type de valeur encadrée |
|
Attribut statique |
Constante |
Classe <<CORBAStruct>> |
Struct |
Classe <<CORBAException>> |
Exception |
Classe <<CORBATypedef>> |
Typedef |
Array |
|
Sequence |
Un composant UML 2.0 est mis en correspondance avec un seul fichier IDL CORBA. Le fichier IDL d'un composant contient tous les éléments CORBA appartenant au composant.
Un type primitif UML 2.0 est mis en correspondance soit avec un type CORBA de base, soit avec un type CORBA natif. Il est fourni pour importation dans le modèle une bibliothèque de types UML 2.0 qui contient tous les types CORBA de base sous forme de types primitifs 2.0. Vous avez également la possibilité de créer un type primitif UML 2.0 portant le même nom qu'un type CORBA de base, qui servira lors de la sélection des types dans le modèle. La liste suivante énumère les types CORBA de base présents dans la bibliothèque de types :
Tout type primitif UML 2.0 portant un nom autre que ceux de la liste ci-dessus représente un type CORBA natif.
Un type CORBA natif génère la définition native
dans le fichier IDL et peut être sélectionné comme type dans le modèle.
Un package UML 2.0 contenu dans un composant UML 2.0 est mis en correspondance avec le module CORBA. La transformation ignore les packages UML 2.0
qui ne sont pas dans un
composant UML 2.0.
Une interface UML 2.0 est mise en correspondance avec l'interface CORBA. Une généralisation UML 2.0 des interfaces UML 2.0 établit une correspondance avec l'héritage des interfaces CORBA. Le tableau suivant répertorie le résultat de la transformation sur les propriétés de l'interface.
Propriété d'interface UML |
Résultat de la transformation |
Name |
Nouvelle interface CORBA dans l'IDL portant le nom spécifié et dont les caractères non autorisés ont été retirés |
Visibility, public |
Interface normale |
Visibility, private |
Interface locale |
Abstract |
Interface CORBA abstraite |
Leaf |
Ignorée |
Les attributs et associations UML 2.0 sont mis en correspondance avec les attributs CORBA. Le tableau suivant répertorie le résultat de la transformation sur les propriétés des attributs.
Résultat de la transformation |
|
Name |
Attribut CORBA portant le même nom |
Type |
Attribut CORBA avec le type de base spécifié |
Valeur "Is Static" et "default" |
Constante CORBA |
Read only |
Attribut CORBA en lecture seule |
Ordering |
Ordre IDL |
Le tableau suivant répertorie le résultat de la transformation sur les propriétés des associations.
Propriété d'association UML |
Résultat de la transformation |
Name |
Attribut CORBA portant le même nom |
Type |
Attribut CORBA avec le type comme fournisseur de cette association |
Valeurs "Is Static" et "default" |
Constante CORBA |
Read only |
Attribut CORBA en lecture seule |
Ordering |
Ordre IDL |
Une opération UML 2.0 qui est déclarée dans une interface UML ou dans une classe UML avec le stéréotype <<CORBAValue>> est mise en correspondance directe avec l'opération IDL. La transformation ignore les autres opérations UML 2.0. Le tableau suivant répertorie le résultat de la transformation sur les propriétés d'opération.
Propriété d'opération UML |
Résultat de la transformation |
Name |
Nouvelle opération CORBA portant le nom spécifié |
Return type |
Type de retour de l'opération CORBA |
Toutes les autres propriétés |
Ignorées |
Opération avec le stéréotype <<CORBAOneway>> |
Opération IDL unidirectionnelle |
stéréotype <<create>> sur une opération dans une classe UML <<CORBAValue>> |
Mise en correspondance avec une opération d'initialiseur de valeur CORBA |
Un paramètre UML 2.0 est mis en correspondance avec le paramètre de l'opération IDL. Le tableau suivant répertorie le résultat de la transformation sur les propriétés des paramètres.
Propriété de paramètre UML |
Résultat de la transformation |
Name |
Nouveau paramètre portant le nom spécifié |
Direction (in, out, inout) |
Paramètre correspondant dans l'IDL ; 'return' est ignoré |
Type |
Paramètre avec le type spécifié |
Visibility |
Ignoré |
Une énumération UML 2.0 est mise en correspondance avec l'énumération CORBA. Elle ne peut contenir que des littéraux d'énumération.
Une classe UML 2.0 avec le stéréotype <<CORBAValue>>
est mise en correspondance avec un type valeur CORBA. Le
stéréotype <<CORBAValue>> s'accompagne d'une propriété appelée
"specification" et typée avec l'énumération {"none",
"custom", "boxed"}. Par défaut, la valeur est
"none".
Si vous spécifiez la propriété comme "custom", elle est mise en correspondance
avec une valeur CORBA personnalisée. Si vous lui affectez la valeur "boxed", elle est mise en correspondance avec une valeur CORBA
encadrée.
Un type valeur CORBA est une entité qui a un état facultatif et une méthode d'initialiseur distincts des propriétés d'une interface. Les membres d'état d'un type valeur CORBA sont représentés par des attributs UML 2.0 dotés du stéréotype <<CORBAState>> et les méthodes d'initialiseur sont représentées par l'application du stéréotype <<create>> provenant du profil de base accompagnant le produit.
Le tableau suivant répertorie le résultat de la transformation sur les propriétés des classes.
Propriété de classe UML |
Résultat de la transformation |
Stereotype |
<<CORBAValue>> |
Name |
Nouveau type valeur portant le nom spécifié |
Visibility |
Ignorée |
Abstract |
Type valeur abstraite |
Attributs avec <<CORBAState>> avec visibilité publique ou privée |
Membre d'état CORBA du type valeur CORBA, avec visibilité publique ou privée |
Opération avec <<create>> |
Méthode de fabrique CORBA du type valeur non abstraite |
Une déclaration de constante CORBA peut apparaître dans la portée d'un fichier IDL, d'un module, d'une interface ou d'un type valeur.
Une constante CORBA apparaissant dans la portée d'une interface
ou d'un type valeur peut être représentée par l'attribut UML statique
dans l'interface ou la classe UML correspondantes.
Une constante CORBA apparaissant dans la portée d'un module CORBA
ou d'un fichier IDL doit être un attribut dans une classe UML avec le
stéréotype <<CORBAConstants>>
qui apparaît dans le package UML (dans le cas d'une constante de module) ou dans le composant UML (dans le cas d'une constante de portée IDL).
Le nom de cette classe est ignoré. Chaque attribut de la classe dotée du stéréotype <<CORBAConstants>> représente une déclaration de constante
.
Une classe UML 2.0 dotée du stéréotype <<CORBAStruct>> est mise en correspondance avec un élément CORBA struct. Cette classe a pour contrainte de n'avoir que des attributs et pas d'opérations. Les membres struct sont représentés par l'attribut ou l'association UML de la classe.
Une classe UML 2.0 dotée du stéréotype <<CORBAException>> représente la définition d'une exception. Ce type de classe peut contenir des attributs, mais ce n'est pas obligatoire.
Dans CORBA 2.4, seule une opération CORBA peut générer une exception ; un attribut CORBA ne peut pas. Il en résulte que si une opération CORBA
génère une exception, celle-ci est représentée dans la propriété RaisedException de l'opération UML correspondante.
La transformation utilise l'élément CORBA typedef pour renommer un type CORBA existant. Une classe UML 2.0 avec le stéréotype <<CORBATypedef>>
est mise en correspondance avec CORBA typedef. La notation complète qui représente CORBA typedef est
une relation UML 2.0 de substitution allant de la classe vers le type CORBA existant.
La spécification CORBA 2.4 préconise l'abandon de la déclaration anonyme
des types CORBA array et sequence. Ce mappage ne prend pas en charge les arrays et les séquences CORBA anonymes.
Tous les types array ou sequence doivent être nommés à l'aide d'une déclaration typedef. Le stéréotype
<<CORBATypedef>> qui
étend la classe UML 2.0 contient une propriété "specification" (dont les valeurs sont "none", "array" et "sequence",
"none" étant la valeur par défaut) et une
propriété de dimensions
(dont la valeur par défaut est vide) qui contient les dimensions du tableau (array) ou de la
séquence (sequence).
Un tableau CORBA est modélisé sous la forme d'une relation UML 2.0 de substitution
allant d'une classe dotée du stéréotype <<CORBATypedef>> vers l'élément UML qui
représente le type de l'élément array.
La propriété "specification" du stéréotype a pour valeur "array" et la propriété "dimensions" a pour valeur la chaîne qui
représente les dimensions du tableau (par exemple, "[3][5]"). Une association allant d'un type construit vers la classe dotée du stéréotype <<CORBATypedef>> modélise
un membre du type construit avec le type sous forme d'array CORBA.
Une séquence CORBA est modélisée sous la forme d'une relation UML 2.0 de substitution
allant d'une classe dotée du stéréotype <<CORBATypedef>> vers l'élément UML qui
représente le type de l'élément sequence.
La propriété "specification" du stéréotype a pour valeur "sequence" et, mais c'est facultatif, la propriété "dimensions" a pour valeur
la valeur de chaîne qui représente la limite supérieure de la séquence (par exemple, "12").
Une association allant d'un type construit vers la classe dotée du stéréotype <<CORBATypedef>> modélise un membre dans le type construit avec l'élément CORBA
sequence pour type.
La transformation génère automatiquement un #include
lorsqu'un type dont la définition figure dans un autre composant est utilisé. La plupart des fichiers IDL CORBA
ont besoin d'inclure le fichier ORB.idl. Lorsque vous devez placer un #include dans un fichier IDL généré d'un autre fichier IDL externe
qui n'est pas modélisé, vous devez
créer une dépendance depuis le composant en cours vers un nouveau composant que vous créez et qui représente le fichier IDL externe. Vous pouvez éviter de générer du code
pour ce nouveau composant en donnant à la propriété generateCode la valeur false.
Cette propriété accompagne le stéréotype du composant provenant du
profil CORBA. Par exemple, pour générer
un "#include <ORB.idl>" dans un fichier IDL, vous devez
créer une dépendance à partir du composant qui modélise
le fichier IDL courant et un nouveau composant appelé ORB. Là encore, pour empêcher
la transformation de générer du code pour ce nouveau composant ORB,
donnez à sa propriété generateCode la valeur false.
Les éléments constructs CORBA suivants ne comportent pas à l'heure actuelle de mappage dans ce profil :
La transformation CORBA permet l'intégration à Team Support ; les utilisateurs peuvent donc automatiquement extraire et ajouter de nouveaux fichiers aux systèmes de contrôle des sources.
Si vous ne voulez pas modifier un modèle source en vue d'une transformation, vous pouvez toujours indiquer des noms de remplacement pour les éléments cible de cette transformation.
Vous pouvez également indiquer des noms de remplacement si vous voulez inclure des détails propres à CORBA dans des modèles indépendants de la plate-forme : des restrictions de nommage par exemple.
Pour la prise en charge de noms de remplacement pour la cible sans modification du modèle source,
créez un mappage de modèles.
Pour créer un modèle de mappage :
1. Vous devez vous trouver dans la perspective de modélisation.
2. Dans la vue Explorateur de modèle, cliquez sur un modèle UML.
3. Dans la barre de menus, cliquez sur Modélisation > Transformations
> Configurer les transformations.
4. Créez une nouvelle transformation d'UML 2.0 en CORBA (vous pouvez, par exemple,
nommer la transformation
Création d'un mappage
).
5. Dans la page Mappage, cliquez sur Créer seulement un modèle de mappage
(pas de transformation).
6. Indiquez le nom du fichier et cliquez sur Exécuter.
Lorsque vous utilisez le mappage de transformation, la transformation CORBA
crée un modèle de mappage, qui est un
modèle distinct possédant un artefact pour chacun des éléments transformables. L'artefact fait référence
à l'élément transformable original et porte le même nom. Pour indiquer un nom de remplacement pour l'élément d'origine
entrez le nouveau nom dans la propriété file
name de l'artefact. Si vous ne modifiez pas cette propriété, la transformation génère l'élément en lui donnant par défaut le
nom de l'artefact. Le tableau suivant donne une liste d'exemples de noms de remplacement.
UML source |
Nom du fichier d'artefact de mappage |
CORBA généré |
Composant1 |
"" |
Fichier Composant1.idl |
Composant2 |
"monIDL" |
Fichier monIDL.idl |
Composant3 |
"monRép\monIDL2" |
Fichier monIDL2.idl dans le dossier "monRép" |
Pour utiliser un modèle de mappage :
1. Vous devez vous trouver dans la perspective de modélisation.
2. Dans la vue Explorateur de modèle, cliquez sur un modèle UML.
3. Dans la barre de menus, cliquez sur Modélisation > Transformations
> Configurer les transformations.
4. Créez une nouvelle transformation d'UML 2.0 en CORBA Transform (vous pouvez, par exemple,
nommer la transformation
Utilisation d'un mappage
).
5. Dans la page Mappage, cliquez sur Transformer en utilisant un modèle de mappage.
6. Cliquez sur le modèle de mappage que vous avez créé précédemment et cliquez sur Exécuter.
Lorsque la transformation s'exécute, elle utilise les noms de remplacement que vous avez éventuellement indiqués dans le modèle de mappage.
Le plug-in de transformation en CORBA apporte toutes les fonctionnalités nécessaires à la validation des modèles par rapport aux risques de problèmes liés à la transformation.
Comme exemples de ces problèmes potentiels, l'on pourrait citer les relations circulaires de généralisation et les conflits de nommage qui provoquent des erreurs de compilation dans le fichier IDL qui est généré. Pour consulter la liste des problèmes qui risquent de se produire dans le
code généré, appliquez le profil au modèle source et exécutez la validation.
Le tableau suivant répertorie quelques-uns des problèmes susceptibles de se produire à l'occasion d'une transformation.
Catégorie |
Risques de problèmes |
Stéréotype CORBAValue |
Un type valeur ne doit pas comporter de discriminants imbriqués autres que les éléments typedef, struct, exception ou enumeration. |
Les membres d'un type valeur doivent avoir des noms uniques. |
|
Un type valeur doit posséder des attributs hérités uniques. |
|
Un type valeur doit posséder des opérations héritées uniques. |
|
Un type valeur peut prendre en charge tout au plus une seule interface non abstraite. |
|
Un type valeur abstraite ne doit hériter que d'autres types valeurs abstraites. |
|
Un type valeur ne peut hériter plusieurs fois de la même classe. |
|
Un type valeur doté de membres d'état ne peut hériter que d'un seul type valeur doté lui aussi de membres d'état. |
|
Un type valeur abstraite ne peut pas avoir de membres d'état. Il ne peut être un type valeur encadrée. |
|
Un type valeur encadrée ne peut pas prendre part à l'héritage. |
|
Un type valeur encadrée doit avoir exactement une seule association ou un seul attribut. |
|
Stéréotype CORBAConstants
|
La classe CORBAConstants ne doit pas avoir d'opérations. |
La classe CORBAConstants ne doit pas avoir de discriminants imbriqués. |
|
Les membres de la classe CORBAConstants doivent avoir des noms uniques. |
|
Stéréotype CORBAException |
La classe CORBAException ne doit pas avoir de discriminants imbriqués. |
Stéréotype CORBAStruct |
Un élément struct ne doit pas être le propriétaire de relations de généralisation ou d'implémentation. |
Un élément struct ne doit pas avoir de discriminants imbriqués. |
|
Un élément struct ne doit pas avoir d'opérations. |
|
Stéréotype CORBATypedef |
Un élément typedef ne doit pas avoir de relations de généralisation. |
Un élément typedef doit avoir une seule relation de substitution. |
|
Un élément typedef ne doit pas avoir d'associations, d'attributs ou d'opérations. |
|
Un élément typedef ne doit pas avoir de discriminants imbriqués. |
|
Stéréotype CORBAState |
Un attribut de membre d'état doit avoir pour propriétaire une classe de type valeur. |
Stéréotype CORBAOneway |
Une opération unidirectionnelle ne doit pas avoir de paramètres du type in ou inout. |
Le type de retour d'une opération unidirectionnelle doit être void. |
|
Une opération unidirectionnelle doit avoir pour propriétaire une interface. |
|
Une opération unidirectionnelle ne doit pas lever d'exceptions. |
|
Énumération |
Les littéraux d'une énumération doivent avoir des noms uniques. |
Composant |
Un composant ne doit pas contenir de composant imbriqué. |
Tous les packages du composant doivent avoir des noms uniques. |
|
Interface |
Les membres d'une interface doivent avoir des noms uniques. |
Une interface ne doit pas contenir d'interface, de package, de type valeur ou de composant imbriqués. |
|
Une interface sans contraintes ne peut pas hériter d'une interface locale. |
|
Une interface doit avoir des opérations héritées uniques. |
|
Une interface doit avoir des attributs hérités uniques. |
|
Une interface ne peut hériter plusieurs fois de la même interface. |
|
Une interface abstraite ne peut hériter que d'autres interfaces abstraites. |
|
Général |
Un modèle ne doit pas comporter d'éléments portant le nom de mots clés CORBA (par exemple, packages, classes, interfaces, operations, properties, parameters et enumerations). |
Un modèle ne doit pas comporter de classes ou d'interfaces avec des relations circulaires de généralisation ou d'implémentation. |
|
Les noms des éléments d'un modèle ne doivent pas exister en double. |
|
Un modèle ne doit pas avoir une hiérarchie mal formée, comme celle, par exemple, qui contiendrait un composant imbriqué. |