Cette technique implique l'utilisation de transformations conçues pour convertir les éléments conceptuels en éléments concrets au sein du même modèle et décrits sur le même diagramme de modèle. Dans ce scénario, tous les éléments de modèle de niveau conception, tels qu'une classe UML, utilisés en entrée directe pour la transformation avec génération de code, sont utilisés pour générer une entité de niveau code correspondante. L'élément de modèle conceptuel de départ est supprimé et sa notation dans le diagramme est remplacée par une référence à l'élément de modèle concret généré. Le diagramme peut toujours indiquer les relations entre l'élément de modèle de code et les autres éléments de modèle conceptuels qui ne sont pas remplacés de la même manière par la transformation.
Grâce à cette technique, vous pouvez également faire glisser des éléments d'un modèle concret, tel que du code Java ou C++, dans un diagramme conceptuel UML stocké dans un modèle UML. Vous pouvez ensuite dessiner certains types de relations entre les éléments conceptuels et les éléments concrets dans le modèle. Cette méthode prend en charge un processus itératif, dans lequel vous utilisez plusieurs fois les transformations qui effectuent cette substitution sémantique sur place. Cela signifie qu'un architecte peut spécifier la première itération de conception à l'aide des modèles conceptuels , puis générer le code à partir de ces portions du modèle révisées et approuvées.
L'architecte peut ensuite continuer à développer la conception dans les itérations suivantes. A mesure que de nouveaux aspects de la conception sont approuvés, il peut les transformer de la même façon. Les portions de la conception précédemment validées par rapport au code sont décrites dans les diagrammes mixtes obtenus, ainsi que les portions n'ayant pas encore été validées. Les éléments validés reflètent toujours l'état actuel de l'implémentation au fur et à mesure de son développement, car il s'agit tout simplement de représentations diagrammatiques du code lui-même.
La modélisation mixte est tout à fait adaptée à une approche de conception itérative. La conception et l'implémentation sont généralement effectuées par différents individus et l'architecte a besoin de disposer d'une visibilité claire des implémentation de développement mais pas d'exercer un contrôle strict. Optez pour cette approche si vous pensez que le fait de pouvoir maintenir l'enregistrement d'intention à des niveaux supérieurs d'abstraction pouvant être décrits à côté de l'état actuel d'implémentation constitue un avantage intéressant par rapport à la charge supplémentaire que représente le maintien à jour des modèles conceptuels.
La modélisation mixte combine les avantages de la modélisation concrète et de la modélisation conceptuelle dans une approche de conception itérative. Elle offre également à l'architecte un niveau de contrôle basé sur la visibilité. Par conséquent, elle offre un niveau de gouvernance supérieur à celui obtenu avec la modélisation concrète ou conceptuelle. Elle permet à l'architecte et aux développeurs de mettre à jour itérativement et simultanément le modèle mixte et l'implémentation. Les diagrammes du modèle mixte reflètent automatiquement et immédiatement leurs modifications.
La modélisation mixte offre les avantages de la modélisation concrète et de la modélisation conceptuelle, mais elle exige un travail de planification et de maintien à jour des diagrammes et du code d'implémentation beaucoup plus important. Chaque itération requiert une transformation qui peut accroître la durée du projet.
La modélisation mixte commence par l'utilisation des modèles conceptuels et se poursuit par la génération du code, comme décrit dans la description du protocole Modèles concrets de départ des modèles conceptuels. Toutefois, avec le protocole de modélisation mixte, vous dirigez la transformation modèle vers code de façon à remplacer les éléments UML, sur lesquels les éléments de code sont basés, par des références directes aux éléments de code générés. Le résultat est un modèle mixte. La modélisation mixte fournit un contenu conceptuel plus abstrait qui reste dans le modèle UML et continue à évoluer comme une expression évolutive de l'intention, alors que les diagrammes indiquent les relations de perfectionnement par rapport au code d'implémentation correspondant. Cela permet aux architectes qui contrôlent les modèles conceptuels de voir immédiatement les décisions que prennent les développeurs lorsqu'ils manipulent le code grâce à l'édition visuelle de L3G.