Visualizing code into Mixed models with UML and UML notation

The design contract management protocol ( DCMP) named Mixed modeling is a software approach in which conceptual models are maintained and iteratively extended throughout the life of the system. You can continue to refine conceptual models throughout the system development process. You can use transformations on the conceptual model to generate 3GL code.
The Mixed modeling protocol combines conceptual and concrete modeling in a unique way. IBM® DevOps Model Architect support and help you to perform these tasks:
  • Create and maintain semantic relationships between types defined in UML and the types defined in third-generation languages.
  • Compose diagrams that mix elements from various language domains.

This protocol uses transformations to convert conceptual elements into concrete elements in the same model and that are displayed in the same model diagram. In this scenario, any design-level model element, such as a UML class, that is used as a direct input to the code-generating transformation is used to generate a corresponding code-level entity. The original conceptual model element is deleted and its notation in the diagram is replaced with a reference to the generated concrete model element. The diagram can still show relationships between the code model element and other conceptual model elements that were not similarly replaced by the transformation.

With this technique, you can also drag elements from a concrete model, such as Java™ or C++ code, to a UML conceptual diagram that is stored in a UML model. You can then draw certain types of relationships between the conceptual elements and the concrete elements in the model. This method supports an iterative process, in which you repeatedly use transformations that perform this in-place semantic substitution. Therefore, an architect can specify the first design iteration using conceptual models and then generate code from those portions of the model that are reviewed and approved.

The architect can then continue the design in subsequent iterations. As more aspects of the design are approved, the architect can transform them in the same way. Portions of the design that were previously committed to code are depicted in the resulting mixed diagrams beside those portions that are not yet committed. The committed elements always reflect the current state of the implementation as it changes, because they diagrammatically reflect the code itself.


The Mixed modeling protocol is well suited for an iterative design approach. Different people typically perform the design and implementation and the architect requires only a visibility of the implementations without requiring strict control. Adopt this approach if you think maintaining an ongoing record of intent that you can be display beside the current implementation is worth the effort of maintaining the conceptual models.


The Mixed modeling protocol provides both a concrete modeling approach as well as the benefits of conceptual modeling within an iterative design approach. The Mixed modeling protocol, by providing visibility, offers a level of control to the architect. As a result, this approach provides a higher degree of governance than either concrete or conceptual seed modelling alone. With this approach, the architect and the developers can iteratively and simultaneously update the mixed model and implementation. The mixed model diagrams automatically and immediately reflect both sets of changes.


The Mixed modeling protocol provides concrete and conceptual model advantages but requires considerably more planning and maintenance of both diagrams and implementation code. Each iteration requires a transformation that can add time to the project.


Mixed modeling begins with the use of conceptual models, and proceeds to generate code in the conceptual models seed concrete models protocol. However, in the Mixed modeling protocol, you direct the model-to-code transformation to replace the UML elements on which the code elements are based with direct references to those generated code elements. The result is a mixed model. Mixed modeling retains more abstract conceptual content in the UML model and continues to evolve as an evolving expression of intent, while the diagrams within it show the refinement relationships to the corresponding implementation code. Architects who control the conceptual models can immediately see the decisions that developers make as they work with the code through 3GL visual editing.

In the following example, you create an UML class called Bus that has a generalization relationship to the BaseVehicle Java class.

Creating a UML class called Transit Bus.

If you run a UML-to-Java transformation on the model, the transformation replaces the UML elements in the model with Java:

UML Bus class is a Java class after transform.

After the transformation runs, you can continue to add UML or Java classes to the model. Modified Java code is also reflected in the model. Mixed modeling is similar to visual editing but with the added capability of adding UML classes.