Transformation d'UML vers CORBA

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.


1. Prise en main

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.

 

2. Caractéristiques de la transformation

 

2.1 Modèle de canevas CORBA

Le modèle de canevas CORBA peut vous aider à vous lancer rapidement dans la modélisation avec CORBA. Pour commencer, cliquez sur Fichier > Nouveau > Modèle UML et sélectionnez Modèle CORBA dans les canevas proposés. Ce choix a pour effet de générer un modèle UML accompagné d'instructions et d'une infrastructure élémentaire pour la création d'un modèle CORBA.

 

2.2 Source de la transformation

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.

2.3 Cible de la transformation

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.

2.4 Profil facultatif

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 :

2.5 Validation du modèle source

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.

2.6 Utilisation d'un modèle de mappage

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.

3. Mappage UML/CORBA

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

3.1 Modèle UML 2.0

Il n'existe pas de correspondance directe entre les modèles UML 2.0 et les éléments CORBA. Ce manque de correspondance signifie que la transformation ne génère pas de code pour l'élément de modèle si aucun composant n'est défini dans le modèle.

3.2 Composant UML 2.0

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.

3.3 Types primitifs UML 2.0

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.

3.4 Package UML 2.0

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.

3.5 Interface 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

3.6 Attributs et associations UML 2.0

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.

Propriété d'attribut UML

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

3.7 Opération UML 2.0

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

3.8 Paramètre UML 2.0

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é

3.9 Enumération UML 2.0

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.

3.10 Classes UML 2.0 dotées du stéréotype <<CORBA Value>>

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

3.11 Attribut statique UML 2.0

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
.

3.12 Classes UML 2.0 dotées du stéréotype <<CORBA Struct>>

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.

3.13 Classes UML 2.0 dotées du stéréotype <<CORBA Exception>>

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.

3.14 Classes UML 2.0 dotées du stéréotype <<CORBA Typedef>>

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.

4. Forward declarations et include dans CORBA

La transformation génère automatiquement les forward declarations de CORBA. Vous ne pouvez pas les modéliser. La transformation réorganise les types dans IDL pour réduire le nombre de forward declarations. Lorsqu'un type est utilisé avant sa définition et que celle-ci ne peut être déplacée avant son utilisation, la transformation génère une forward declaration 
du type dans la portée qui convient.

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.

5. Références croisées entre modèles

La transformation d'UML vers CORBA prend en charge les modèles comportant des références croisées. Supposons par exemple qu'Interface A dans le modèle courant peut étendre Interface B provenant 
d'un autre modèle. Dans ce cas, la transformation crée un #include du fichier IDL dans laquelle le type utilisé apparaît (Interface B, en l'occurrence). 
La transformation ne gère pas l'emplacement au sein du système de fichiers des fichiers IDL inclus. C'est à vous de gérer les chemins relatifs des fichiers IDL qui sont générés 
en utilisant un modèle de mappage.

 

6. Les éléments Constructs CORBA qui ne sont pas mis en correspondance

Les éléments constructs CORBA suivants ne comportent pas à l'heure actuelle de mappage dans ce profil :

7. Prise en charge des technologies usuelles de transformation

 

7.1 Intégration avec Team Support

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.

7.2 Modèle de mappage des transformations

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.

7.3 Validation

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é.