Développement guidé par le modèle: qu'est-ce qu'une transformation?

A (programme) transformation est une fonction qui donne une instance de représentation de programme, calcule une autre.

la représentation du programme peut être arbitraire, mais elle est souvent un arbre de syntaxe abstraite (AST) ou un graphique (par exemple, UML); vous pouvez même inclure du byte-code comme représentation du programme. Comme les fonctions mathématiques, les transformations peuvent être "partielle" (qui est, ne fonctionnent que sous certaines [éventuellement compliqué] condition.)

j'aime personnellement la terminologie transformer pour désigner la fonction elle-même, et transformation pour désigner l'acte ou le résultat de l'application de la transformation pour obtenir une nouvelle représentation.

en général, une transformation de programme (globale) peut affecter la représentation entière même si elle est énorme, mais typiquement les transformations individuelles ne modifient qu'une petite partie laissant la plus grande partie du programme représentation seul. Abstraitement, l'instance de représentation de programme entière est traitée par la transformation pour produire une autre instance de représentation de programme entièrement nouvelle. Puisque les instances de représentation ont tendance à être grandes, ceci est souvent mis en œuvre en ayant la transformation simplement modifier l'instance de représentation existante. Ces "petites" transformations que vous pouvez penser comme ayant des paramètres supplémentaires qui les concentrent sur la partie spécifique de la représentation à laquelle ils feront un changement.

comme les fonctions mathématiques, les transformations composent pour produire des transformations" plus grandes " (qui sont également partielles, comme les conditions composent aussi). Habituellement vous écrivez un ensemble de transformations pour transformer une représentation de programme dans son intégralité, puisque aucune transformation ne traitera l'instance de représentation entière en une seule étape. Le fait que vous puissiez les composer vous permet d'écrire beaucoup de "petites" transformations qui collectivement atteindre votre but, de sorte que vous obtenez une sorte de modularité dans la traduction sémantique, qui est pourquoi les gens aiment l'idée de programmes de transformations.

comme les fonctions mathématiques, vous pouvez mettre en œuvre de telles transformations en écrivant le code de procédure. Un tel code inspecte des bits du modèle original, et produit des changements au modèle pendant qu'ils courent, mais ceci est généralement maladroit.

donc de telles transformations sont souvent écrites dans un soi-disant "déclaratif" forme règles qui contiennent des paires de modèles et un condition . Chaque règle est interprétée comme, "si vous voyez le dessin du côté gauche, et la condition correspond, alors changez la représentation du programme pour correspondre au dessin du côté droit". Les variables de modèle permettent au modèle de désigner des morceaux de la représentation de programme originale pour passer à travers la transformation intacte (normalement à traiter par certains autre transformation). Bien que ces règles soient appelées "déclaratives" (parce qu'elles ne ressemblent pas au code conventionnel), elles ne représentent que certaines fonctions équivalentes et ne sont donc pas déclaratives au sens voulu. Les règles ont tendance à être beaucoup plus lisibles que le code de procédure équivalent, souvent parce que les motifs sont écrits dans la syntaxe de surface des représentations source et cible.

en pratique, les transformations individuelles ne s'appliquent qu'aux les lieux de la représentation, et l'ordre dans lequel ils sont appliqués ("message"). Pour gérer cela, les outils de transformation (de programme) fournissent souvent un moyen de "metaprogram" pour contrôler le point de focalisation et l'ordre d'application de la règle.

ces idées s'appliquent à ce que l'on appelle le" développement basé sur le modèle", qui n'est qu'une transformation appliquée à un modèle de haut niveau pour générer du code de bas niveau, ou pour transformer du code de bas niveau en un autre code de bas niveau. Vous pouvez même utiliser ces idées pour construire des outils d'ingénierie inverse, par exemple, cartographier le code de bas niveau à un modèle abstrait. Notre DMS Software Reengineering Toolkit est un outil de transformation de programme, ont à la fois des transformations procédurales et des réécritures source-à-source, utilisés à toutes ces fins.

le flux de développement de base de MDD va des modèles d'application jusqu'à la réalisation en cours, en passant par les transformations de modèles subséquentes. Cela permet de réutiliser des modèles et d'exécuter des systèmes sur différentes plateformes. En effet, au niveau de la réalisation, le logiciel en cours d'exécution repose sur une plate-forme spécifique (défiée pour un domaine d'application spécique) pour son exécution.

outre les modèles, les transformations de modèles représentent l'autre ingrédient crucial de MDD et permettre à défyne mappages entre différents modèles. La transformation est effectuée entre un modèle source et un modèle cible, mais elle est en fait défiée sur les métamodèles respectifs.

peuvent être classées comme suit:: - modèle pour les transformations de modèles - transformation de texte à modèle (utilisé pour générer du code logiciel, de la documentation, ou d'autres Artéfacts textuels).

MDE fournit conceptuel approprié langues (par exemple, QVT ou ATL) pour defyning les transformations de modèles, afin de fournir aux concepteurs des solutions optimisées pour spécifier les règles de transformation. Évidemment, puisqu'à la fin les modèles sont encodés sous forme de fichiers, on peut penser à utiliser les langages de programmation habituels pour défier leurs transformations. Cependant, ce qui abaisse le niveau d'abstraction de l'ensemble du cadre de modélisation et se termine généralement en produire des logiciels encombrants et irrécupérables.

une transformation dans le développement basé sur le modèle est le résultat que nous obtenons lors du traitement d'un modèle. Cette sortie peut être un autre modèle, ou code source.

dans l'approche MDA (Model-Driven Architecture), nous pouvons transformer un PIM (Platform Independent Model) en un PSM (Platform Specific Model) à travers un processus de transformation. Ensuite, nous pouvons transformer le PSM en code source, encore une fois via une transformation ultérieure.

D'autres approches comme ABSE transformez un modèle directement en code source. Ici, un modèle ABSE génère directement le code source final parce que ses modèles fonctionnent comme des mini-programmes (dans un générateur de type coopératif): aucune autre transformation n'est nécessaire. Comme la plupart des autres approches MDD, ABSE nécessite un support d'outillage. Dans ce cas, c'est AtomWeaver .