Transformation UML vers EJB

 

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.

 

Caractéristiques de la transformation

 

Source de transformation

Cible de transformation

Conteneur EJB cible

Profil de transformation EJB

Onglets de configuration des transformations UML en EJB

Onglet Cible

Onglet Entité

Onglet Session

Onglet Avancé

Interprétation des objets source

Types primitifs

Packages

Classes non marquées

Interfaces non marquées

Enumération non marquée

classes <<entity>>

classes <<service>>

classes <<messageprocessor>>

Associations

Références EJB

Scénario de réapplication

Support de traitement des relations entre des éléments UML et des beans d'entreprise visualisés ou des classes Java

Support pour technologies de transformation communes

Intégration avec fonctionnalité d'équipe

Mappage de transformation

Relations source-à-cible

 

 

Source de transformation

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.

 

Cible de transformation

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.

 

Conteneur EJB cible

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 beans CMP 2.x ne peuvent pas être générés
  • Les beans CMP 1.1 ne doivent être générés qu'avec des interfaces distantes
  • Les beans BMP (Bean Managed Persistence) doivent être générés avec des interfaces distantes uniquement
  • Les beans session doivent être générés avec des interfaces distantes uniquement
  • Les beans pilotés par message ne peuvent pas être générés

 

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.

 

Profil de transformation EJB

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.

 

Onglets de configuration des transformations UML en EJB

 

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.

 

Onglet Cible

 

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.

 

Onglet Entité

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.

 

Onglet Session

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.

 

Onglet Avancé

Pour obtenir de plus amples informations relatives à l'onglet Avancé, consultez la documentation Transformation UML vers Java.

 

Interprétation des objets source

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.

Types primitifs

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.

 

Packages

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.

 

Classes non marquées

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

Interfaces non marquées

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

Enumération non marquée

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.

 

classes <<entity>>

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

 

Correspondance des types de champs CMP et BMP

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 de findXxx (voir la table des noms de localisateur.)
  • Emet javax.ejb.FinderException
  • Emet java.rmi.RemoteException

 

Nom du localisateur

 

Nom d’opération UML

Nom de méthode de localisation

xxx

findXxx

findXxx

findXxx

FindXxx

findXxx

 

Type de retour du localisateur d'interface home

 

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 locale
  • Nom d’interface distante

<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 de sélection

 

Nom d’opération UML

Nom de méthode de sélection

xxx

ejbSelectXxx

selectXxx

ejbSelectXxx

SelectXxx

ejbSelectXxx

ejbSelectXxx

ejbSelectXxx

 

Type de retour de sélection

 

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 de localisateur d'interface home distante

 

Nom d’opération UML

Nom de méthode de localisation

xxx

findXxx

findXxx

findXxx

FindXxx

findXxx

 

Type de retour du localisateur d'interface home distante

 

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
(s'il existe des interfaces locales)

Interface home distante

(s'il existe des interfaces distantes)

Classe d'implémentation des beans

 

Nom du localisateur d'interface home

 

Nom de l'opération UML

Nom de méthode de localisation

xxx

findXxx

findXxx

findXxx

FindXxx

findXxx

ejbFindXxx

findEjbFindXxx

EjbFindXxx

findEjbFindXxx

 

Nom du localisateur de classe bean

 

Nom de l'opération UML

Nom de méthode de localisation

xxx

ejbFindXxx

findXxx

ejbFindXxx

FindXxx

ejbFindXxx

ejbFindXxx

ejbFindEjbFindXxx

EjbFindXxx

ejbFindEjbFindXxx

 

Type de retour du localisateur d'interface home

 

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 locale
  • Nom d’interface distante

<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 d’interface locale
  • Nom d’interface distante

<nom de classe non source (par exemple, Chaîne, Entier, etc.)>

  • Nom d’interface locale
  • Nom d’interface distante

 

Type de retour du localisateur de classe bean

 

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.

 

Classes <<service>>

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 :

 

Classes internes

Ignorées.

 

Interfaces internes

Ignorées.

 

Classes <<messageprocessor>>

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.

 

Associations

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

  • Valeur supérieure point1 = 1
  • Valeur supérieure point1 = -1
  • Multiplicité BeanB = 1
  • Multiplicité BeanB = -1, Type CMR BeanA = java.lang.Collection
  • Valeur supérieure point2 = 1
  • Valeur supérieure point2 = -1
  • Multiplicité BeanA = 1
  • Multiplicité BeanA = -1, Type CMR BeanB = java.lang.Collection

 

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 :

 

 

 

 

 

Références EJB

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

 

 

 

 

Scénario de réapplication

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.

 

Explication détaillée sur la réaction de la transformation

 

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.

 

Beans entity CMP 2.x

 

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 :

 

Beans entity CMP 1.1

 

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 :

 

 

Beans entity BMP

 

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 :

 

Beans session sans état et avec état

 

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 :

 

Beans pilotés des un message

 

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 :

 

Support de traitement des relations entre des éléments UML et des beans d'entreprise visualisés ou des classes Java

 

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

 

Support pour technologies de transformation communes

 

Intégration avec fonctionnalité d'équipe

 

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.

Mappage de transformation

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

Relations source-à-cible

 

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.