Cette approche permet à une entreprise, ayant une forte culture de gouvernance, de développer un ensemble détaillé et sémantiquement riche de modèles conceptuels UML qui décrivent un système.
Les architectes peuvent générer le code à partir de ces modèles et le régénérer suivant les évolutions du modèle. Lorsqu'un architecte a créé le modèle détaillé de niveau classe à l'aide du langage UML, il peut appliquer directement une transformation à ce modèle conceptuel pour générer la structure du code, ou dans de nombreux cas le code de compilation réel, de l'application.
Le développeur développe ensuite l'implémentation, conformément aux instructions relatives à la structure du nouveau modèle de code, en éditant visuellement le code dans les diagrammes de notation UML ou à l'aide d'un éditeur de code. Si la structure du modèle de code doit être modifiée, ou si un développeur rencontre un problème avec la conception de haut niveau du système, l'architecte peut réexaminer la modification proposée et l'implémenter directement dans le modèle UML.
Une transformation inverse est appliquée au code de développement, ce qui produit des modèles UML temporaires qui sont comparés aux états de développement des modèles UML de départ. Cette comparaison est également appelée synchronisation. Procéder de cette façon permet d'identifier facilement tout écart entre l'implémentation et le contrat de conception, et permet à l'architecte d'apporter des modifications.
Les transformations inverses, qui peuvent être appliquées plusieurs fois pendant le cycle de développement, offrent un moyen de contrôle strict de la conformité au contrat de conception. Le modèle UML peut être considéré comme le modèle maître, car il évolue en permanence tout au long du processus de développement.
Lorsque l'architecte applique à nouveau la transformation du modèle UML, le code existant est écrasé, mais l'architecte prend toutes les précautions possibles pour ne pas écraser le travail détaillé du développeur. Dans ce flux de travail, l'architecte génère les aspects de conception d'une ou plusieurs applications, en veillant à ce que les activités de codage manuel restantes n'altèrent pas de façon significative l'architecture et restent conformes au contrat de conception.
La modélisation synchronisée est la mieux adaptée aux applications très critiques et lorsque les exigences et la documentation de conformité sont très strictes. Ce protocole est le plus avantageux pour les entreprises qui pratiquent un important contrôle architectural, lorsque les interfaces sont spécifiées de façon approfondie par les architectes et lorsque les développeurs respectent strictement ces spécifications.
Cette approche peut être utilisée lorsque tous les aspects architecturaux significatifs d'une implémentation peuvent être dérivés de la spécification du modèle, et lorsque le recours à une transformation automatisée et, dans certains cas, à des patterns de conception prédéfinis, présente un avantage certain. Ce flux de travail est particulièrement approprié lorsque le travail de conception est effectué en interne mais que le travail d'implémentation est externalisé, ou lorsque plusieurs applications utilisent une infrastructure architecturale commune, comme pour les projets SOA, et que les applications, fonctions et services présentent un grand nombre de points communs.
La modélisation synchronisée permet aux architectes de conserver des expressions complètes et détaillées de l'intention architecturale de l'application. Elle offre une certaine liberté de création aux développeurs, mais elle fait l'objet d'une étroite surveillance par l'architecte, qui veille à la résolution ou à la modification rapide des écarts par rapport aux exigences. Les architectes disposent d'outils qui leur permettent de comparer la conception au code, car les modèles ne sont pas remplacés à partir de la conception d'origine. La modélisation synchronisée, comme son nom l'implique, fournit un modèle opérationnel puissant de gestion des modifications architecturales.
La modélisation synchronisée offre une certaine liberté de création aux développeurs. Cependant, la gestion des modèles peut se révéler coûteuse, de même que les transformations inverses du code d'implémentation effectuées dans le but de le comparer aux objectifs de conception initialement définis. Les entreprises qui optent pour cette approche doivent faire appel à des architectes qui comprennent la sémantique UML et qui peuvent concevoir une application complète à l'aide de la syntaxe UML détaillée.