La transformation d'UML en EJB transforme les éléments de modèle Unified Modeling Language (UML) en beans enterprise et en code Java. La transformation d'UML vers EJB est la même que la transformation d'UML vers Java mais elle peut également générer des beans enterprise à partir d'éléments UML qui sont marqués avec des stéréotypes provenant du profil de transformation en EJB.
Vous devez être familier de la transformation UML vers Java avant d'utiliser la transformation UML vers EJB.
Onglets de configuration des transformations UML en EJB
Interprétation des objets source
Support pour technologies de transformation communes
Intégration avec fonctionnalité d'équipe
Vous pouvez sélectionner dans la vue Explorateur de modèle un ou plusieurs éléments comme source de la transformation d'UML en EJB. Le tableau suivant énumère les éléments acceptés comme source valide par la transformation :
Source |
Résultat |
Modèle UML |
Transforme tous les packages, toutes les classes et toutes les interfaces présents dans le modèle |
Package UML |
Transforme le package et toutes les classes et les interfaces qu'il contient |
Classe UML |
Transforme la classe et la totalité de ses attributs, opérations, classes et interfaces Remarque : Le parent de la classe doit être un package UML |
Interface UML |
Transforme l'interface et la totalité de ses attributs, opérations, classes et interfaces Remarque : Le parent de l'interface doit être un package UML |
Enumération UML |
Transforme l'énumération et tous les littéraux de l'énumération Remarque : Le parent de l'énumération doit être un package UML |
Pour générer des beans enterprise à partir d'un modèle source, vous devez appliquer à ce dernier le profil de transformation en EJB et vous devez marquer les éléments du modèle avec les stéréotypes issus du profil de transformation en EJB.
La transformation UML vers EJB accepte comme cible un seul projet EJB. Vous pouvez créer le projet EJB avec ou sans projet client. La transformation génère des codes dans le premier dossier source détecté dans le projet EJB (en principe, ejbModule) et dans le premier dossier source détecté dans le projet client (en principe, src), s'il existe un projet client.
La version du conteneur d'EJB qui est associé au projet EJB affecte la transformation UML vers EJB. Les règles à suivre pour le fonctionnement et le traitement corrects de cette transformation sont en effet différentes pour chaque version de conteneur d'EJB. Le tableau suivant énumère les règles qui sont associées aux différentes versions de conteneurs d'EJB :
Version du conteneur EJB |
Règles affectant la transformation |
2.1 |
Les beans à persistance gérée par le conteneur (CMP) de version 1.1 ne doivent être générés qu'avec des interfaces distantes |
2.0 |
Les beans CMP 1.1 ne doivent être générés qu'avec des interfaces distantes |
1.1 |
|
Les règles indiquées ci-dessus doivent être suivies avant l'exécution de la transformation, faute de quoi celle-ci ne traiterait pas le modèle source et n'opérerait aucune transformation.
Le profil de transformation en EJB définit les stéréotypes suivants que la transformation UML vers EJB interprète pour générer des beans enterprise : le tableau suivant énumère les stéréotypes définis par le profil de transformation en EJB :
Stéréotype |
Elément cible |
Interprétation de la transformation UML vers EJB |
<<entity>> |
Classe UML |
Représente un bean entity |
<<service>> |
Classe UML |
Représentes un bean session dont la propriété de stéréotype (hasState) a au départ la valeur False, autrement dit, le bean session est sans état. |
<<messageprocessor>> |
Classe UML |
Représente un bean piloté par message |
<<ID>> |
Attribut UML |
Représente un champ CMP ou BMP à utiliser comme élément de la clé primaire d'un bean entity. |
<<Requête>> |
Opération UML |
Représente une méthode de requête sur un bean entity |
Le profil de la transformation en EJB définit aussi les contraintes suivantes :
Lors de la validation d'un modèle avec le profil de transformation en EJB, ces contraintes génèrent des avertissements. Avant d'exécuter cette transformation, vous devez corriger les problèmes à l'origine de ces avertissements. Cela dit, les avertissements ne vous empêchent pas d'exécuter la transformation.
La fenêtre de configuration des transformations EJB comporte cinq onglets : Cible, Entité, Session, Mappage et Commun. La présente section décrit la manière dont les trois premiers onglets affectent la transformation EJB.
L'onglet Cible permet de sélectionner le projet EJB cible dans lequel la transformation en EJB génère les fichiers en sortie. Vous pouvez créer un conteneur cible même s'il existe déjà un projet EJB. Chaque projet est associé à un seul conteneur EJB. La transformation EJB prend en charge toutes les versions existantes de conteneurs EJB fournies par l'assistant de projet EJB.
La version du conteneur de projet EJB cible peut limiter le nombre des options proposées dans les onglets Entity et Session. Pour obtenir de plus amples informations relatives aux restrictions apportées à chacun des types de conteneur EJB, consultez la section Conteneur EJB cible.
L'onglet Entity permet de personnaliser les beans entity qui viennent d'être générés. La configuration peut se faire à l'aide de deux options de l'onglet Entity : type de bean entity et interface de bean entity. La figure ci-après montre l'onglet Entity dans la fenêtre de configuration des transformations EJB :
Selon le version du conteneur EJB présente dans le projet, vous ne pourrez sélectionner que certaines combinaisons de propriétés avant de pouvoir exécuter la transformation EJB. Le tableau suivant énumère les types de beans entity pris en charge par la transformation, les interfaces prises en charge par les beans entity et l'interface sélectionnée par défaut :
Version du conteneur EJB |
Type de bean entity |
Interfaces prises en charge pour les beans entity |
Sélection par défaut |
2.x |
CMP 2.x |
Local et distant |
Interfaces locales uniquement |
2.x |
CMP 1.1 |
Distant |
Interfaces distantes uniquement |
2.x |
BMP |
Local et distant |
Interfaces locales uniquement |
1.1 |
CMP 2.x |
Aucun |
Non disponible |
1.1 |
CMP 1.1 |
Distant |
Interfaces distantes uniquement |
1.1 |
BMP |
Distant |
Interfaces distantes uniquement |
Les sélections par défaut répertoriées dans le tableau reflètent le comportement par défaut de l'assistant de création de beans entity.
Tout choix d'une combinaison non valide d'options entraîne l'apparition d'un message d'erreur en haut de la fenêtre de configuration des transformations EJB et l'indisponibilité du bouton Exécuter qui lance la transformation. Il suffit de sélectionner une combinaison valide d'options pour que ce bouton redevienne utilisable et pour faire disparaître le message d'erreur.
L'onglet Session permet de personnaliser la génération d'interfaces pour les beans session qui viennent d'être générés. La figure ci-après montre l'onglet Session dans la fenêtre de configuration des transformations EJB :
Selon le version du conteneur EJB présente dans le projet, vous ne pourrez sélectionner que certaines combinaisons de propriétés avant de pouvoir exécuter la transformation EJB. Le tableau suivant énumère les interfaces prises en charge pour les beans session, selon la version du conteneur EJB, ainsi que l'interface sélectionnée par défaut :
Version du conteneur EJB |
Interfaces prises en charge pour les beans session |
Sélection par défaut |
1.1 |
Distant |
Interfaces distantes uniquement |
2.0 |
Local et distant |
Interfaces distantes uniquement |
2.1 |
Local et distant |
Interfaces distantes uniquement |
Tout choix d'une combinaison non valide d'options entraîne l'apparition d'un message d'erreur en haut de la fenêtre de configuration des transformations EJB et l'indisponibilité du bouton Exécuter qui lance la transformation. Il suffit de sélectionner une combinaison valide d'options pour que ce bouton redevienne utilisable et pour faire disparaître le message d'erreur.
Pour obtenir de plus amples informations relatives à l'onglet Avancé, consultez la documentation Transformation UML vers Java.
La présente section explique comment la transformation UML vers EJB interprète les éléments d'un modèle UML et décrit les sorties générées par la transformation.
La transformation UML vers EJB interprète les types primitifs de la même manière que la transformation UML vers Java. Pour plus d’informations, veuillez consulter la documentation Transformation d'UML en Java.
La transformation UML vers EJB interprète les packages de la même manière que la transformation UML vers Java : elle les transforme en packages Java. Pour plus d’informations, veuillez consulter la documentation Transformation d'UML en Java.
La transformation UML vers EJB interprète les classes non marquées de la même manière que la transformation UML vers Java : elle les transforme en classes Java. Pour plus d’informations, veuillez consulter la documentation Transformation d'UML en Java.
Si une classe non marquée contient des attributs dont le type est d'une classe avec un stéréotype <<entity>>, <<service>> ou <<messageprocessor>>, la transformation ne générera pas les attributs. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
La transformation UML vers EJB interprète les interfaces non marquées de la même manière que la transformation UML vers Java : elle les transforme en interfaces Java. Pour plus d’informations, veuillez consulter la documentation Transformation d'UML en Java.
Si une interface non marquée contient des attributs dont le type est d'une classe avec un stéréotype <<entity>>, <<service>> ou <<messageprocessor>>, la transformation ne génére pas les attributs. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
La transformation UML vers EJB interprète les énumerations non marquées de la même manière que la transformation UML vers Java : elle les transforme en interfaces Java. Pour plus d’informations, veuillez consulter la documentation Transformation d'UML en Java.
La transformation UML vers EJB transforme une classe marquée avec le stéréotype <<entity>> en un bean entity CMP 2.x, CMP 1.1 ou BMP dont le nom est celui de la classe UML source. Le type du bean qui est généré correspond à l'option sélectionnée dans l'onglet Entity de la fenêtre de configuration des transformations EJB.
La transformation génère toujours les classes Java suivantes pour les beans entity :
La transformation génère les classes Java suivantes lorsque, dans l'onglet entity, l'on clique sur interfaces distantes uniquement :
La transformation génère les classes Java suivantes lorsque, dans l'onglet entity, l'on clique sur interfaces locales uniquement :
La transformation génère les classes Java suivantes lorsque, dans l'onglet Entity, l'on clique sur interfaces locales et distantes :
La transformation génère toutes les classes dans le dossier du package qui est généré pour le package parent de la classe UML source. Si vous créez un modèle UML sans package, la transformation génère un package par défaut du nom d'ejbs.
La transformation génère les fichiers de la classe bean et de la classe clé dans l’arbre source du projet EJB cible.
La transformation génère les quatre fichiers d'interfaces dans l’arbre source du projet client du projet EJB cible. Si aucun projet client n’existe, la transformation génère les fichiers d’interface dans le projet EJB cible.
La transformation ajoute des données qui définissent le bean entity au descripteur de déploiement (ejb-jar.xml).
Relations de généralisation
Si la classe UML source du bean entity détient une généralisation (une extension d'extension, par exemple) d’une autre classe UML avec le stéréotype <<entity>>, le bean entity représenté par la deuxième classe devient la superclasse EJB pour le bean entity à générer.
Les deux beans entity doivent être de même type. Ils doivent donc être tous les deux des CMP 2.x, des CMP 1.1 ou des BMP. Si, par exemple, le le superbean est un bean entity CMP 2.x, tous les beans enfants devront l'être aussi. Si le superbean n'est pas du même type que celui du bean enfant attendu, la transformation générera le bean enfant sans relation de généralisation.
Relations de réalisation
Si la classe UML source du bean entity comporte des relations de réalisation (par exemple, d'implémentation) avec des éléments d’interface, les interfaces représentées par les interfaces sources sont implémentées par les quatre interfaces (distante, home, locale et home locale).
Attributs non marqués - CMP 2.x
La transformation transforme les attributs de la classe source UML en champs CMP du bean entity avec les propriétés énumérées dans le tableau suivant :
Propriété du champ CMP 2.x |
Valeur du champ CMP |
Nom |
Nom de l'attribut UML, avec le premier caractère du nom du champ en minuscule |
Type |
Type déterminé par le type d’attribut (voir la table de correspondance des types) |
Champ clé |
Faux |
Générer le champ dans la classe d'implémentation du bean |
Faux |
Générer "getter" et "setter" |
Vrai |
Promouvoir "getter" et "setter" vers les interfaces locales |
Vrai (s'il existe des interfaces locales) |
Promouvoir "getter" et "setter" vers les interfaces distantes |
Vrai (s'il existe des interfaces distantes) |
IsArray |
Vrai si l’attribut UML a une valeur supérieure limitée |
Si le type d’attribut est celui d’un autre bean entity CMP 2.x, la transformation ne transforme pas l’attribut en champ CMP mais elle suppose qu’il fait partie d’une association qui doit être transformée en relation d’EJB. Mais si le type d’attribut est celui d’un autre bean d'entreprise qui n'est pas un bean entity CMP 2.x, la transformation ne transforme pas l’attribut en champ CMP ni en association. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Attributs non marqués - CMP 1.1
La transformation transforme les attributs de la classe source UML en champs CMP du bean entity avec les propriétés énumérées dans le tableau suivant :
Propriétés du champ CMP 1.1 |
Valeur du champ CMP |
Nom |
Nom de l'attribut UML, avec le premier caractère du nom du champ en minuscule |
Type |
Type déterminé par le type d’attribut (voir la table de correspondance des types) |
Champ clé |
Faux |
Générer le champ dans la classe d'implémentation du bean |
Faux |
Générer "getter" et "setter" |
Vrai |
Promouvoir "getter" et "setter" vers les interfaces locales |
Faux |
Promouvoir "getter" et "setter" vers les interfaces distantes |
Vrai (toujours) |
IsArray |
Vrai si l’attribut UML a une valeur supérieure limitée |
Si le type d’attribut est celui d’un autre bean entity ou enterprise, la transformation ne transforme pas l’attribut en champ CMP ou en association. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Attributs non marqués - BMP
La transformation transforme les attributs de la classe source UML en champs BMP du bean entity avec les propriétés énumérées dans le tableau suivant :
Propriétés du champ BMP |
Valeur du champ BMP |
Nom |
Nom de l'attribut UML, avec le premier caractère du nom du champ en minuscule |
Type |
Type déterminé par le type d’attribut (voir la table de correspondance des types) |
Champ clé |
Faux |
Générer le champ dans la classe d'implémentation du bean |
Vrai |
Générer "getter" et "setter" |
Vrai |
Promouvoir "getter" et "setter" vers les interfaces locales |
Vrai (s'il existe des interfaces locales) |
Promouvoir "getter" et "setter" vers les interfaces distantes |
Vrai (s'il existe des interfaces distantes) |
IsArray |
Vrai si l’attribut UML a une valeur supérieure limitée |
Si le type d’attribut est celui d’un autre bean entity ou d'un EJB, la transformation ne transforme pas l’attribut en champ BMP ou en association. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Attributs <<id>> - CMP 2.x and CMP 1.1
La transformation transforme également en champs CMP les attributs de la classe UML source qui sont marqués avec l'attribut <<id>>, mais avec des valeurs de propriétés différentes, indiquées dans le tableau ci-après. Ces champs CMP aident à former la clé primaire.
Propriété du champ CMP 2.x et CMP 1.1 |
Valeur du champ CMP |
Nom |
Nom de l'attribut UML, avec le premier caractère du nom du champ en minuscule |
Type |
Type déterminé par le type d’attribut (voir la table de correspondance des types) |
Champ clé |
Vrai |
Générer le champ dans la classe d'implémentation du bean |
Faux |
Générer "getter" et "setter" |
Vrai |
Promouvoir "getter" et "setter" vers les interfaces locales |
Faux |
Promouvoir "getter" et "setter" vers les interfaces distantes |
Faux |
IsArray |
Vrai si l’attribut UML a une valeur supérieure limitée |
Si le type d’attribut est celui d’un autre bean entity ou enterprise, la transformation ne transforme pas l’attribut en champ CMP ou en association. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Attributs <<id>> - BMP
La transformation transforme également en champs BMP les attributs de la classe UML source qui sont marqués avec l'attribut <<id>>, mais avec des valeurs de propriétés différentes, indiquées dans le tableau ci-après. Ces champs BMP aident à former la clé primaire.
Propriétés du champ BMP |
Valeur du champ BMP |
Nom |
Nom de l'attribut UML, avec le premier caractère du nom du champ en minuscule |
Type |
Type déterminé par le type d’attribut (voir la table de correspondance des types) |
Champ clé |
Vrai |
Générer le champ dans la classe d'implémentation du bean |
Vrai |
Générer "getter" et "setter" |
Vrai |
Promouvoir "getter" et "setter" vers les interfaces locales |
Faux |
Promouvoir "getter" et "setter" vers les interfaces distantes |
Faux |
IsArray |
Vrai si l’attribut UML a une valeur supérieure limitée |
Si le type d’attribut est celui d’un autre bean entity ou enterprise, la transformation ne transforme pas l’attribut en champ clé BMP ou en association. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Comme le montre le tableau suivant, la transformation génère les champs CMP et BMP avec des types basés sur le type de l'attribut source :
Type d’attribut UML |
Type de champ CMP/BMP |
booléen |
booléen |
octet |
octet |
caractère |
caractère |
variable flottante |
variable flottante |
int |
int |
long |
long |
court |
court |
Booléen |
java.lang.Boolean |
Octet |
java.lang.Byte |
Caractère |
java.lang.Char |
Variable flottante |
java.lang.Float |
Entier |
java.lang.Integer |
Long |
java.lang.Long |
Court |
java.lang.Short |
Chaîne |
java.lang.String |
autre |
Nom qualifié complet |
Opérations non marquées
La transformation transforme les opérations non marquées sur la classe UML source en méthodes métiers sur le bean entity. Au départ, l'opération est transformée de la même manière qu'une opération sur une classe UML non marquée. La transformation applique la désignation en minuscule en faisant en sorte que le premier caractère du nom de la méthode soit en minuscule s'il s'agit d'un caractère en majuscule valide. L'opération transformée est ajoutée aux classes énumérées dans le tableau suivant, avec quelques modifications.
Classe |
Modifications des méthodes |
Classe de bean |
Aucun changement |
Interface locale |
Méthode d’interface |
Interface distante |
Méthode d’interface, émet java.rmi.RemoteException |
Opérations <<requête>> - CMP 2.x
La transformation transforme les opérations <<requête>> sur la classe UML source en l’un de ces deux types de méthodes de requêtes : la méthode de localisation et la méthode de sélection. Cette dernière n'existe que dans les beans entity CMP 2.x.
La transformation génère des méthodes de localisation dans les classes énumérées dans le tableau suivant, avec quelques modifications.
Classe |
Modifications des méthodes |
Interface home locale (s'il existe des interfaces locales) |
|
Interface home distante (s'il existe des interfaces distantes) |
|
Nom d’opération UML |
Nom de méthode de localisation |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
Types de retours d’analyse syntaxique de transform Java |
Type de retour de méthode de localisation |
Collection mappée (Collection, List, Set etc,) |
java.util.Collection |
<nom de classe source>[] |
java.util.Collection |
<nom de classe source> OU vide |
|
<nom de type défini par l'utilisateur>[] |
java.util.Collection |
<nom de classe non source (par exemple, Chaîne, Entier, etc.)>[] |
java.util.Collection |
<nom de type défini par l'utilisateur> |
Générer une méthode de sélection et non une méthode de localisation |
<nom de classe non source (par exemple, Chaîne, Entier, etc.)> |
Générer une méthode de sélection et non une méthode de localisation |
La transformation EJB crée une tâche qui indique que vous avez besoin d'ajouter manuellement une requête au descripteur de déploiement pour chacune des méthodes de localisation qui sont générées.
La transformation transforme une opération requête en méthode de sélection si la visibilité pour l’opération est privée ou si le type de retour est différent du nom de la classe UML source et que le bean entity est du type CMP 2.x.
Visibilité de l’opération |
Type de retour |
Type de méthode |
Privée |
Egal au nom de la classe source |
Méthode de sélection |
Non privée |
Egal au nom de la classe source |
Méthode de localisation |
Privée |
Différent du nom de la classe source |
Méthode de sélection |
Non privée |
Différent du nom de la classe source |
Méthode de sélection |
La transformation génère des méthodes de sélection dans la classe de bean avec les modifications suivantes :
Nom d’opération UML |
Nom de méthode de sélection |
xxx |
ejbSelectXxx |
selectXxx |
ejbSelectXxx |
SelectXxx |
ejbSelectXxx |
ejbSelectXxx |
ejbSelectXxx |
Types de retours d’analyse syntaxique de transform Java |
Type de retour de méthode de sélection |
Collection mappée (Collection, List, Set etc,) |
Nom qualifié complet du type de collection (java.util.Collection, par exemple) |
<nom de classe source>[] |
java.util.Collection |
<nom de classe source> OU vide |
Nom d’interface locale |
<nom de type défini par l'utilisateur>[] |
java.util.Collection |
<nom de classe non source (par exemple, Chaîne, Entier, etc.)>[] |
java.util.Collection |
<nom de type défini par l'utilisateur> |
Nom de type défini par l'utilisateur |
<nom de classe non source (par exemple, Chaîne, Entier, etc.)> |
Nom de classe non source |
La transformation EJB crée une tâche qui indique que vous avez besoin d'ajouter manuellement une requête au descripteur de déploiement pour chacune des méthodes de sélection qui sont générées.
Opérations <<requête>> - CMP 1.1
La transformation transforme les opérations <<requête>> sur la classe UML source en un type unique de méthode de requête : les méthodes de localisation. En effet, les beans entity CMP 1.1 ne prennent pas en charge les méthodes de sélection qui ne sont disponibles que pour les beans entity CMP 2.x. Par conséquent, quels que soient le type de retour et la visibilité de l'opération <<requête>>, la transformation génère toujours une méthode de localisation dans l'interface home distante du bean entity.
Comme le montre le tableau suivant, la transformation génère des méthodes de localisation dans l'interface home distante, avec quelques modifications :
Classe |
Modifications des méthodes |
Interface home distante |
|
Nom d’opération UML |
Nom de méthode de localisation |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
Types de retours d’analyse syntaxique de transform Java |
Type de retour de méthode de localisation |
Collection mappée (Collection, List, Set etc,) |
java.util.Collection |
<nom de classe source>[] |
java.util.Collection |
<nom de classe source> OU vide |
Nom d’interface distante |
<nom de type défini par l'utilisateur>[] |
java.util.Collection |
<nom de classe source (par exemple, Chaîne, Entier, etc.)>[] |
java.util.Collection |
<nom de type défini par l'utilisateur> |
Nom d’interface distante |
<nom de classe non source (par exemple, Chaîne, Entier, etc.)> |
Nom d’interface distante |
La transformation EJB crée une tâche qui indique que vous avez besoin d'ajouter manuellement une requête au descripteur de déploiement pour chacune des méthodes de localisation qui sont générées.
Opérations <<requête>> - BMP
La transformation transforme les opérations <<requête>> sur la classe UML source en un type unique de méthode de requête : les méthodes de localisation. En effet, les beans entity BMP, quelle que soit leur version, ne prennent pas en charge les méthodes de sélection qui ne sont disponibles que pour les beans entity CMP 2.x. Par conséquent, quels que soient le type de retour et la visibilité de l'opération <<requête>>, la transformation génère toujours une méthode de localisation dans la classe d'implémentation des beans. La transformation génère alors des méthodes de localisations dans les interfaces existantes du bean entity.
Comme le montre le tableau suivant, la transformation génère des méthodes de localisation dans les classes suivantes, avec quelques modifications :
Classe |
Modifications des méthodes |
Interface home locale |
|
Interface home distante (s'il existe des interfaces distantes) |
|
Classe d'implémentation des beans |
|
Nom de l'opération UML |
Nom de méthode de localisation |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
ejbFindXxx |
findEjbFindXxx |
EjbFindXxx |
findEjbFindXxx |
Nom de l'opération UML |
Nom de méthode de localisation |
xxx |
ejbFindXxx |
findXxx |
ejbFindXxx |
FindXxx |
ejbFindXxx |
ejbFindXxx |
ejbFindEjbFindXxx |
EjbFindXxx |
ejbFindEjbFindXxx |
Types de retours d’analyse syntaxique de transform Java |
Type de retour de méthode de localisation |
Collection mappée (Collection, List, Set etc,) |
java.util.Collection |
<nom de classe source>[] |
java.util.Collection |
<nom de classe source> OU vide |
|
<nom de type défini par l'utilisateur>[] |
java.util.Collection |
<nom de classe non source (par exemple, Chaîne, Entier, etc.)>[] |
java.util.Collection |
<nom de type défini par l'utilisateur> |
|
<nom de classe non source (par exemple, Chaîne, Entier, etc.)> |
|
Types de retours d’analyse syntaxique de transform Java |
Type de retour de méthode de localisation |
Collection mappée (Collection, List, Set etc,) |
java.util.Collection |
<nom de classe>[] |
java.util.Collection |
<nom de classe> OU vide |
Nom de classe clé |
Classes internes
Ignorées.
Interfaces internes
Ignorées.
La transformation UML vers EJB transforme une classe au stéréotype <<service>> en un bean session géré par conteneur, sans état ou avec état dont le nom est égal à celui de la classe UML source. La transformation génère toujours les classes Java suivantes pour les beans session :
La transformation génère les classes Java suivantes lorsque, dans l'onglet Session, l'on clique sur interfaces distantes uniquement :
La transformation génère les classes Java suivantes lorsque, dans l'onglet Session, l'on clique sur interfaces locales uniquement :
La transformation génère les classes Java suivantes lorsque, dans l'onglet Session, l'on clique sur interfaces locales et distantes :
La transformation génère toutes les classes dans le dossier du package qui est généré pour le package parent de la classe UML source. Si vous créez un modèle UML sans package, la transformation crée un package par défaut du nom d'ejbs.
La transformation génère le fichier classe bean dans l’arbre source du projet EJB cible.
La transformation génère les quatre fichiers d'interfaces dans l’arbre source du projet client du projet EJB cible. Si aucun projet client n’existe, la transformation génère les fichiers d’interface dans le projet EJB cible.
La transformation ajoute les données qui définissent le bean session dans le descripteur de déploiement (ejb-jar.xml).
Propriété du stéréotype - hasState
Chaque classe UML avec un stéréotype <<service>> possède une propriété appelée hasState. Lorsque la valeur de hasState est false, la transformation génère cette classe UML sous forme de bean session sans état. Inversement, lorsque la valeur de hasState est true, la transformation génère la classe UML sous forme de bean session avec état.
Remarque : La propritété de stéréotype n'affecte que les classes UML générées par la transformation sous forme de nouveaux beans session.
Par défaut, la propriété hasState a une valeur de false, ce qui est cohérent avec les paramètres par défaut de l'assistant de création de beans session.
Relations de généralisation
Si la classe UML source du bean session comporte une relation de généralisation (par exemple, une relation d'extension) avec une autre classe UML avec le stéréotype <<service>> et que la propriété hasState de ce stéréotype est de la même valeur, le bean session représenté par la classe devient la superclasse EJB pour le bean session à générer.
Relations de réalisation
Si la classe UML source du bean session comporte des relations de réalisation (par exemple, d'implémentation) avec des éléments d’interface, les interfaces représentées par les interfaces sources sont implémentées par les quatre interfaces (distante, home, locale et home locale).
Attributs
La transformation transforme les attributs sur la classe UML source en propriétés Java dans la classe de bean. Pour obtenir de plus amples informations relatives à la manière de transformer les attributs, consultez la documentation Transformations UML vers Java. La transformation applique la désignation en minuscule en faisant en sorte que le premier caractère du nom de la propriété soit en minuscule s'il s'agit d'un caractère en majuscule valide.
Si le type de l'attribut est celui d'un autre bean enterprise, la transformation enh EJB ne génère pas de champ ni d'association pour le bean session. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Opérations
La transformation transforme les opérations sur la classe UML source en méthodes métier sur le bean session. Au départ, l'opération est transformée de la même manière qu'une opération sur une classe UML non marquée. La transformation applique la désignation en minuscule en faisant en sorte que le premier caractère du nom de la méthode soit en minuscule s'il s'agit d'un caractère en majuscule valide. L'opération transformée est ajoutée aux classes énumérées dans le tableau suivant, avec quelques modifications.
Classe |
Modifications des méthodes |
Classe de bean |
Aucun changement |
Interface locale |
Méthode d’interface |
Interface distante |
Méthode d’interface, émet java.rmi.RemoteException |
La transformation applique les règles suivantes pour déterminer le type de retour d'opération en fonction des paramètres de l'opération :
o L'opération détient des paramètres de retour et de sortie
o L'opération détient plusieurs paramètres de sortie
Classes internes
Ignorées.
Interfaces internes
Ignorées.
La transformation UML vers EJB transforme une classe avec le stéréotype <<messageprocessor>> en un bean piloté par message qui porte un nom égal à celui de la classe UML source et qui a des données par défaut. La transformation génère les classes Java suivantes :
La transformation génère la classe dans le dossier du package qui est généré pour le package parent de la classe UML source. Si vous créez un modèle UML sans package, la transformation crée un package par défaut du nom d'ejbs.
La transformation génère le fichier classe bean dans l’arbre source du projet EJB cible.
La transformation ajoute au descripteur de déploiement les données qui définissent le bean piloté par message (ejb-jar.xml).
Relations de généralisation
Si la classe UML source du bean piloté par message détient une généralisation (une extension d'extension, par exemple) d’une autre classe UML avec le stéréotype <<messageprocessor>>, le bean piloté par message représenté par la deuxième classe devient la superclasse EJB pour le bean entity à générer.
Relations de réalisation
Ignorées.
Attributs
La transformation transforme les attributs sur la classe UML source en propriétés Java dans la classe de bean. Pour obtenir de plus amples informations relatives à la manière de transformer les attributs, consultez la documentation Transformations UML vers Java. Si le type de l'attribut est celui d'un autre bean enterprise, la transformation enh EJB ne génère pas de champ ni d'association pour le bean session. Elle écrira alors un message dans le journal pour indiquer que l'attribut source ne sera pas transformé.
Opérations
La transformation transforme les opérations sur la classe ULM source en méthodes Java normales comme si le bean piloté par message était une classe Java.
Classes internes
Ignorées.
Interfaces internes
Ignorées.
D'une manière générale, la transformation transforme les associations de la même manière que le fait la transformation UML vers Java : elle transforme en propriétés Java les attributs des points d'infléchissement.
Si le point d'infléchissement de l'association est une classe avec un stéréotype <<entity>>, <<service>> ou <<messageprocessor>>, la transformation ne transformera pas ce point. Mais elle écrira un message dans le journal qui se trouve dans le répertoire des métadonnées pour indiquer que la propriété du point d'infléchissement n'a pas été transformée. Seule exception à ce cas de figure : lorsque l'association relie deux classes avec des stéréotypes <<entity>>, toutes deux générées sous forme de beans CMP 2.x. Dans ce cas, la transformation transforme l'association UML en relation EJB 2.0, que l'on désigne également sous le nom de relation gérée par conteneur (container-managed relationship ou CMR). Le tableau suivant montre les correspondances existant entre les propriétés des associations et les propriétés des relations EJB :
Propriété de l’association |
Propriété d’une relation EJB |
Point1 |
BeanA |
Point2 |
BeanB |
Nom point1 |
Nom CMR BeanB |
Nom point2 |
Nom CMR BeanA |
Navigabilité point1 |
Navigabilité BeanB |
Navigabilité point2 |
Navigabilité BeanA |
|
|
|
|
La figure ci-après montre deux classes UML avec des stéréotypes <<entity>>. L'association entre les classes est générée en CMR si la transformation génère les deux classes entity sous forme de beans entity CMP 2.x.
Une fois la transformation effectuée, le descripteur de déploiement comporte une entrée qui décrit la relation CMR entre AEntity et BEntity. Comme le montre la figure suivante, le descripteur de déploiement du projet est capable d'afficher l'association existant entre les deux beans entity CMP 2.x :
Le tableau ci-dessous répertorie les façons dont la transformation transforme des dépendances et génère des références EJB pour les classes avec un stéréotype <<entity>>, <<service>> ou <<messageprocessor>>.
Source de la dépendance UML |
Cible de la dépendance UML |
Cible EJB |
Classe <<entity>> |
Classe <<entity>> |
Référence EJB |
Classe <<entity>> |
Classe <<service>> |
Référence EJB |
Classe <<messageprocessor>> |
Classe <<entity>> |
Référence EJB |
Classe <<messageprocessor>> |
Classe <<service>> |
Référence EJB |
Classe <<service>> |
Classe <<entity>> |
Référence EJB |
Classe <<service>> |
Classe <<service>> |
Référence EJB |
Lorsqu'un projet cible Java 2 Platform, Enterprise Edition (J2EE) comprend au moins un bean dont le nom et l'espace de nom sont identiques à une classe UML de la transformation, un scénario de réapplication peut intervenir. L'on parle de scénario de réapplication lorsque le type du bean enterprise existant correspond au type de celui qui doit être généré pour la classe correspondante dans le modèle UML.
En revanche, lorsque le type du bean enterprise à générer est incompatible avec celui du bean existant, c'est un scénario de collision qui se produit. Dans un tel scénario, la transformation d'UML en EJB n'actualise pas le bean existant et ne génère pas de nouveau bean.
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans entity CMP 2.x :
Bean Enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
CMP 2.x |
CMP 2.x |
Réapplication |
Mise à jour des champs et des méthodes CMP |
CMP 2.x |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes CMP comme s'il s'agissait scénario de réapplication CMP 1.1/CMP 1.1 classique |
CMP 2.x |
BMP |
Réapplication |
Mise à jour des zones et des méthodes BMP comme s'il s'agissait d'un scénario de réapplication BMP/BMP classique |
CMP 2.x |
Session (avec état ou sans état) |
Collision |
Le bean session demeure intact |
CMP 2.x |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans entity CMP 1.1.x :
Bean Enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
CMP 1.1 |
CMP 2.x |
Réapplication |
Mise à jour des zones et des méthodes CMP comme s'il s'agissait d'un scénario de réapplication CMP 2.x/CMP 2.x classique |
CMP 1.1 |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes CMP |
CMP 1.1 |
BMP |
Réapplication |
Mise à jour des zones, des méthodes et des associations BMP comme s'il s'agissait d'un scénario de réapplication BMP/BMP classique |
CMP 1.1 |
Session (avec état ou sans état) |
Collision |
Le bean session demeure intact |
CMP 1.1 |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans entity BMP :
Bean Enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
BMP |
CMP 2.x |
Réapplication |
Mise à jour des zones et des méthodes CMP comme s'il s'agissait d'un scénario de réapplication CMP 2.x/CMP 2.x classique |
BMP |
CMP 1.1 |
Réapplication |
Mise à jour des zones et des méthodes CMP comme s'il s'agissait d'un scénario de de réapplication CMP 1.1/CMP 1.1 classique |
BMP |
BMP |
Réapplication |
Mise à jour des champs et des méthodes BMP |
BMP |
Session (avec état ou sans état) |
Collision |
Le bean session demeure intact |
BMP |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans session :
Bean Enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
Session (avec état ou sans état) |
CMP 2.x |
Collision |
Le bean CMP 2.x demeure intact |
Session (avec état ou sans état) |
CMP 1.1 |
Collision |
Le bean CMP 1.1 demeure intact |
Session (avec état ou sans état) |
BMP |
|
Le bean BMP demeure intact |
Session (avec état) |
Session (avec état uniquement) |
Réapplication |
Mise à jour des champs et des méthodes du bean session |
Session (avec état) |
Session (sans état uniquement) |
Collision |
Le bean session sans état demeure intact |
Session (sans état) |
Session (avec état uniquement) |
Collision |
Le bean session avec état demeure intact |
Session (sans état) |
Session (sans état uniquement) |
Réapplication |
Mise à jour des champs et des méthodes du bean session |
Session (avec état ou sans état) |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans pilotés par message :
Bean Enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
Piloté par message |
CMP 2.x |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
CMP 1.1 |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
BMP |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
Session (avec état ou sans état) |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
Piloté par message |
Réapplication |
Mise à jour des champs et des méthodes du bean piloté par message |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les classes UML non marquées :
Stéréotype sur classe UML |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
Non marquée |
CMP 2.x |
Réapplication |
Mise à jour des champs et des méthodes du bean entity CMP 2.x dans son interface distante existante |
Non marquée |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes du bean entity CMP 1.1 dans son interface distante existante |
Non marquée |
BMP |
Réapplication |
Mise à jour des champs et des méthodes du bean entity BMP dans son interface distante existante |
Non marquée |
Session (avec état ou sans état) |
Réapplication |
Mise à jour des champs et des méthodes de la session dans son interface distante existante |
Non marquée |
Piloté par message |
Réapplication |
Génération d'une classe Java normale |
Dans les scénarios de réapplication pour les classes UML non marquées, les modifications de code apportées à l'interface distante du bean enterprise peuvent provoquer des erreurs de construction dans le projet EJB. Ces erreurs de construction se produisent parce que le code modifié de l'interface distant n'est pas conforme aux spécifications EJB pour les interfaces distantes. Si vous prévoyez de remplacer la totalité du bean enterprise, vous devrez le supprimer avant d'exécuter la transformation EJB.
La présente section examine plus en détail la réaction de la transformation à un scénario de réapplication en indiquant ce qu'il convient d'attendre de la transformation après une réapplication.
En cas de scénario de réapplication pour un bean entity CMP 2.x, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean entity CMP 1.1, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean entity BMP, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean session, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean piloté par message, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
Le tableau ci-dessous répertorie les façons dont la transformation UML vers EJB traite les relations :
Elément source UML |
Elément cible visualisé |
Type de relation |
Résultat de transformation |
Classe avec stéréotype <<entity>> ou <<service>> |
Interface Java (interface UML) |
Implémentation |
Le bean enterprise généré permet d'implémenter l'interface visualisée |
Classe avec stéréotype <<entity>> ou <<service>> |
Interface Java (interface UML) |
Réalisation |
Le bean enterprise généré permet d'implémenter l'interface visualisée |
Classe avec stéréotype <<entity>> |
Bean entity visualisé (composant UML) |
Association |
Relation CMR |
Classe avec stéréotype <<entity>>, <<service>> ou <<messageprocessor>> |
Bean entity ou bean session visualisé (composant UML) |
Dépendance |
Référence EJB |
La transformation UML vers EJB prend en charge l’intégration à un fonctionnement en équipe. Quand vous exécutez la transformation sur un projet cible dans un environnement où c'est la source qui contrôle, le système vous invite à ajouter de nouveaux fichiers au contrôle source et à contrôler les fichiers existants.
La transformation UML vers EJB offre un support pour le mappage similaire à celui que fournit la transformation UML vers Java. Pour obtenir des informations relatives à la configuration et l'utilisation d'un modèle de mappage pour exécuter une transformation, consultez la documentation Transformation UML vers Java.
Lorsque les classes source sont marquées pour être transformées en EJB, la transformation utilise le nom mappé de la classe source comme nom de bean de l’EJB généré.
Si la fonction Générer des relations de source à cible est activée, la transformation ajoute des balises à la documentation de l'API des classes et des interfaces Java qui sont générées. Ces balises contiennent des informations qui permettent aux outils de remonter des fichiers générés à l'élément source UML d'origine.
Dans le cas d'EJB générés, tous les fichiers Java générés par la transformation pour un bean d'entreprise font pointer vers la classe UML source unique les balises de la documentation de l'API source-vers-cible.
Conditions d'utilisation | Retours d'informations
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.