This approach helps an organization with a strong governance culture to develop a detailed and semantically rich set of UML conceptual models that describe a system.
Architects can generate code from these models and regenerate as the model evolves. After creating the detailed class-level model using UML, the architect can apply a transformation directly to this conceptual model to generate the code structure, or in many cases the actual compiling code, for an application.
The developer then develops the implementation within the structural guidelines of the new code model by visually editing the code in UML notational diagrams or by using a code editor. If the structure of the code model needs to be modified or if a developer has a concern with the high-level design of the system, the architect can review the proposed change and implement it directly in the UML model.
A reverse transformation is applied to the evolving code, producing temporary UML models which are compared with the evolving states of the original UML models. This comparison is also called reconciling. This approach provides a means to readily see when the implementation is deviating from the design contract and offers the architect an opportunity to make changes.
Reverse transformations can occur many times in the development cycle and provides a strict control over the design contract. The UML model can be seen as the master model because it is continuously evolving throughout the development process.
When the architect reapplies the UML model transformation, the existing code is overwritten, with precautions taken by the architect not to overwrite the detailed work of the developer. In this workflow, the architect is generating the design aspects of one or more applications, leaving little potential for the remaining hand-coding activities to alter something that is architecturally significant or that would violate a design contract.
Reconciled Modeling is best suited to highly critical applications and where requirement and compliance documentation are very strict. This protocol is most beneficial to organizations that practice strong architectural control, where interfaces are extensively specified by architects, and where developers adhere strictly to those specifications.
This approach can be used when all architecturally significant aspects of an implementation can be derived from the model specification and when high-value is gained by the use of automated transformation and, in some cases, predefined design patterns. This workflow is particularly appropriate when the design work is being done in-house but implementation is being outsourced, or where multiple applications target a common architectural framework, such as for service oriented architecture (SOA) projects, so that there is a lot of commonality from one application, feature, or service to the next.
With Reconciled Modeling, the architects to retain complete, detailed expressions of architectural intent of the application. Reconciled Modeling does provide some creative freedom to the developers but it is closely monitored by the architect to ensure that deviations from the requirements are quickly resolved or modified. Architects have the tools to compare and contrast the design against the code because models are not replaced from the original design. Reconciled Modeling, as the name implies, provides a strong operational model for managing architectural change.
Reconciled Modeling provides little creative freedom to the developers. In Reconciled Modeling, models can be costly to maintain the models. Reverse transformations of the implementation code to compare the code with the design goals set forth in the beginning can also be costly. Organizations that choose this approach must employ architects who understand UML semantics and can design a complete application using detailed UML syntax.