Questo approccio consente ad un'organizzazione con una cultura di controllo rigida di sviluppare un insieme dettagliato e semanticamente completo di modelli concettuali UML che descrivono un sistema.
Gli architetti possono generare un codice da questi modelli e rigenerarlo mano mano che il modello si evolve. Dopo aver creato il modello di livello classe dettagliato mediante UML, un architetto può applicare una trasformazione direttamente a questo modello concettuale, per generare la struttura del codice o, in molti casi, il codice di compilazione effettivo, per un'applicazione.
Lo sviluppatore sviluppa quindi l'implementazione all'interno delle istruzioni strutturali del nuovo modello di codice modificando visivamente il codice in diagrammi di notazione UML o utilizzando un editor di codice. Se la struttura del modello di codice deve essere modificata o se uno sviluppatore ha interesse nella progettazione di livello elevato del sistema, l'architetto può rivedere la modifica proposta e implementarla direttamente nel modello UML.
Una trasformazione inversa viene applicata al codice in evoluzione, producendo modelli UML temporanei, che vengono confrontati agli stati in evoluzione dei modelli UML originali. Questo confronto viene anche chiamato riconciliazione. Questo approccio fornisce un mezzo per verificare rapidamente se l'applicazione si sta allontanando dal contratto di progettazione e consente all'architetto di apportare modifiche.
Le trasformazioni inverse possono verificarsi molte volte nel ciclo di sviluppo e forniscono un controllo rigido sul contratto di progettazione. Il modello UML può essere visto come un modello principale, in quanto è in continua evoluzione in tutto il processo di sviluppo.
Quando l'architetto riapplica la trasformazione del modello UML, il codice esistente viene sovrascritto, con precauzioni prese dall'architetto per non sovrascrivere il lavoro dettagliato dello sviluppatore. In questo flusso di lavoro, l'architetto genera gli aspetti di progettazione di una o più applicazioni, lasciando un minimo potenziale per le attività di codifica manuale restanti, per modificare qualcosa che sia significativo dal punto di vista dell'architettura o che violerebbe un contratto di progettazione.
Il modeling riconciliato è adatto ad applicazioni altamente critiche e laddove requisiti e documentazione di conformità sono molto rigidi. Questo protocollo è particolarmente vantaggioso per le organizzazioni che praticano un forte controllo dell'architettura, laddove le interfacce sono ampiamente specificate dagli architetti e laddove gli sviluppatori aderiscono strettamente a queste specifiche.
Questo approccio può essere utilizzato quando tutti gli aspetti significativi di un'implementazione dal punto di vista dell'architettura possono derivare dalla specifica del modello e quando un valore elevato viene acquisito dall'utilizzo di trasformazioni automatizzate e, in alcuni casi, da pattern di progettazione predefiniti. Questo flusso di lavoro è particolarmente appropriato quando il lavoro di progettazione viene eseguito in-house, ma l'implementazione viene eseguita esternamente o laddove più applicazioni hanno come destinazione un framework di architettura comune, ad esempio progetti SOA (service oriented architecture), per cui esistono vari punti in comune per un'applicazione, funzione, servizio e il successivo.
Con il modeling riconciliato, agli architetti possono di mantenere espressioni dettagliate e complete di modalità di architettura dell'applicazione. Il modeling riconciliato fornisce una certa libertà creativa agli sviluppatori ma è strettamente monitorato dall'architetto, per garantire che le deviazioni dai requisiti siano risolte o modificate rapidamente. Gli architetti hanno gli strumenti per confrontare e contrastare la progettazione rispetto al codice, perché i modelli non vengono sostituiti dal progetto originale. Il modeling riconciliato, come implica il nome, fornisce un forte modello operativo per la gestione delle modifiche dell'architettura.
Il modeling riconciliato fornisce una certa libertà creativa agli sviluppatori. Nel Modeling riconciliato, i modelli possono essere costosi per gestire i modelli. Anche le trasformazioni inverse del codice di implementazione per il confronto del codice agli obiettivi della progettazione impostati all'inizio possono essere costosi. Le organizzazioni che scelgono questo approccio devono utilizzare architetti che conoscono la semantica UML e possono progettare un'applicazione completa utilizzando la sintassi UML dettagliata.