La relation entre éléments source et cible est définie par un ensemble de règles contenues dans une transformation. L'exécution de ces règles est basée sur des jeux de règles qui déterminent comment traverser l'ensemble source d'éléments. La transformation peut dépendre d'un profil appliquant des informations complémentaires à ses propres règles.
Les services de transformation comblent le vide entre les modèles UML et le code, ainsi qu'entre les modèles à différents niveaux d'abstraction. Les transformations peuvent s'exercer,entre autres :
Les transformations peuvent aussi implémenter des patterns pour convertir des éléments d'une forme à une autre. Les transformations installées avec le produit sont disponibles via des commandes dans Rational Software Architect.
Le point de départ le plus courant pour une transformation est un modèle indépendant de la plateforme (PIM, platform-independent model), tel qu'un modèle de classe. Un modèle de classe contient des éléments de conception sans aucune référence aux caractéristiques d'une implémentation. Vous pouvez créer, modifier et annoter un modèle de classe, puis utiliser des transformations pour générer un modèle spécifique à une plateforme (PSM, platform-specific model), tel qu'un diagramme de rubrique Java™ ou un texte de niveau code.
Dans le cadre de leur mise en forme, les patterns peuvent aussi définir et fournir des extensions aux transformations, le rôle de ces extensions étant de définir des règles additionnelles à exécuter lors de la rencontre de niveaux spécifiques d'abstraction ou de métamodèles particuliers. Une implémentation courante de ce concept est un pattern de conception qui fournit des règles de transformation pour générer un code spécifique. Ces règles peuvent étendre une transformation en code (par exemple, une transformation en Java ou C++) pour fournir à la sortie générée un code spécifique au pattern en question.
Pour appliquer une transformation particulière, vous avez besoin des quatre éléments d'information suivants :
Dans sa forme la plus élémentaire, une transformation de modèle inclut les étapes suivantes :
Une transformation terminée a pour résultat le modèle ou le texte cible, ainsi qu'un enregistrement de la transformation à des fins de traçabilité. Dans les transformations de modèles en texte, la sortie générée peut être du code Java ou C++, des fichiers DDL pour la création et le peuplement d'une base de données, des tests unitaires ou des diagrammes de visualisation reflétant les diagrammes de modèle correspondants. L'enregistrement de la transformation inclut une mappe établissant le lien entre les éléments dans le modèle source et les éléments correspondants dans la cible ; il montre également quelles parties du mappage ont été utilisées pour chaque partie de la transformation.
Vous pouvez créer de nouvelles transformations à l'aide de l'API de transformation. Le service de transformation est
générique et ne fait aucune hypothèse quant au modèle source, au modèle cible ou à l'implémentation de la transformation
elle-même. Même si ce service contient un moteur de transformation par défaut, rien n'empêche les auteurs de
transformations de recourir à un moteur complètement différent. Cependant, en construisant leurs transformations avec le
moteur par défaut, ils bénéficieront de l'environnement de débogage de la logique, du mécanisme d'extensibilité et des
futures améliorations de cette architecture.