Quelques limites rencontrées

Je souhaitais dans ce chapitre, partager quelques limitations que j'ai rencontrées lors de la transformation de classes à partir des modèles de transformation livrés en standard avec EA.

Classes d'association

Lors de la transformation d'une classe d'association avec le modèle Java, EA crée une classe déconnectée des classes sources et cibles auxquelles elle est reliée.

Diagramme 1 : classes d'association

Pour contourner cette limitation, lorsque je modélise des classes d'analyse destinées à être transformées en classes PSM, je remplace la classe d'association par une classe standard et la relie aux classes source et cible qui l'entourent.

Un exemple de classe standard pouvant se substituer à une classe d'association est illustré sur le diagramme 1 ci-contre.

Associations qualifiées

EA propose de transformer les associations qualifiées dont la multiplicité est supérieure à 1 du côté de la classe cible (classe dont les objets sont sélectionnés par la valeur du qualificatif), par l'ajout d'un attribut à la classe source avec pour type, la classe de collection paramétrée dans les options générales ou dans les propriétés de la classe cible (voir la description du champ Collection Class for Qualified Multiplicity au paragraphe Paramètres de transformation de classes).

Ecran 1 : propriétés d'une association qualifiée Diagramme 2 : associations qualifiées

Cependant, le processus de transformation ne supporte pas l'ajout des qualificatifs de l'association à la déclaration de la classe de collection paramétrée.
Par exemple, si je choisis d'utiliser la collection java de type Generics java.util.Map, je ne peux paramétrer que la valeur java.util.Map<#TYPE#> pour la classe de collection idoine, sans pouvoir insérer de variable du style #QUALIFIERS# ou #KEYS# pour ajouter à la déclaration le type de données des qualificatifs.

D'autre part dans bons nombres de cas, la multiplicité de l'association qualifiée du côté de la classe cible est égale à 1 et la transformation n'est alors pas effectuée.

Pour contourner ces limitations, vous pouvez personnaliser les modèles de transformation Java et utiliser en particulier les macros de substitution de champ %connectorSourceQualifier% et %connectorDestQualifier% pour disposer des qualificatifs déclarés dans le champ Qualifier(s) des onglets Source Role et Target Role des propriétés de l'association (voir écran 1 ci-contre).

Autre issue possible, certainement la plus évidente mais qui peut s'avérer dans certains cas insuffisante, remplacer l'association qualifiée par une simple association en déclarant les qualificatifs dans la classe cible (voir diagramme 2 ci-contre).

Type de données multiples

Lors de la personnalisation de la table de conversion des types génériques UML en types de données Java (voir le paragraphe Conversion des types de données), il n'est pas permis de définir deux types de données génériques différents pour un même type de données du langage cible.
EA affiche en effet le message d'erreur This datatype already exists..

Il est pourtant parfois utile de différencier dans la modélisation d'attributs de classes, deux types d'attributs différents donnant lieu au final à l'emploi d'un même type de données dans le langage cible de la transformation.
J'en veux pour preuve le besoin de distinguer par exemple les attributs contenant des horaires (horaire d'ouverture d'un magasin, horaire de passage d'un train...) de ceux contenant réellement une date (date de fermeture exceptionnelle d'un magasin, date de réservation d'un billet de train...).
D'un point de vue métier pour la modélisation des classes d'analyse, la distinction peut être faite par l'emploi des deux types génériques tels que time et date.
Ces deux mêmes types génériques peuvent donner lieu après transformation en Java à un type de données java.lang.Date, alors que leur transformation en tables MySql pourrait se traduire par des types de données distincts TIME et DATE.

Ecran 2 : template personnalisé de conversion de types de données

La solution que je retiens pour contourner cette limite consiste à réaliser la conversion des types génériques de mes attributs de classes d'analyse directement dans les modèles de transformation.
Je crée pour cela un template personnalisé nommé par exemple Conversion prenant en paramètre le type générique UML à convertir et appelé chaque fois qu'une conversion de données est requise (voir écran 2 ci-contre).

Pour conclure et aller plus loin, terminons par la lecture du dernier chapitre de cet article....