![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Problems of broken lineage
There are several workflows that might need to address models of broken lineage.
The layers in Model-Driven Architecture (MDA), as shown in Figure 1, include computationally independent models, platform independent models, platform-specific models, and software code. The process of moving downwards or upwards from one layer to another layer typically crosses modeling domains. This crossing of domains is often automated using transformation. Adding automation to MDA is typically called model-driven development, or MDD.
Model-driven development (MDD) is a concept whereby a system or application (typically in software. but it can really be anything) is visually modeled by using one or more modeling languages and then implemented with code, often written in a third-generation language that targets a specific runtime environment.
Figure 1. Transformations in Model-Driven Architecture (MDA)
When transforming across domains, such as from a process model to a service model or from Java™ code to a UML model, elements or the models' identities can be created or mutated if the two domains do not share identities when representing the same entity. For example, when Java™ code is generated by a Rational Software Architect transformation element, identities can be inserted into the code as comments or as annotations, thus the identities can be preserved when code is later refactored. In such a case, it is possible to make changes on either side and to make sense of the changes during both forward and reverse engineering.
However, in cases where the code is used to generate and maintain a UML representation, as shown in Figure 2, there will be no identities to preserve. Thus, new identities will be created on each execution of the transformation. If the models are to be useful for comparison purposes, the alignment of the newly generated (source) model to the previously existing (target) model must re-establish element identity.
Figure 2. Successive transformation between domains
Model fusion (described later) is built into many transformations, and it is most often used when user intervention is expected. But if a development or build process must remain purely automatic, then model alignment followed by an automated merge would be preferred over fusion.
When moving models across software versions, the UML metamodel and the notational metamodel both typically change. Examples of identity-mutating migrations are from IBM® Rational Rose® or IBM® Rational® XDE® to Rational Software Architect or from Rational Software Architect Version 6 to Rational Software Architect Version 7. Moving from XDE to Rational Software Architect, for example, changes the underlying metamodel from UML 1 to UML 2. This is a massive change with many changes to elements and many new elements, especially within the notational metamodel.
An example of the scope of the changes when moving to Rational Software Architect software is a customer migration that we performed with 100 individual models in two streams. One was a product variant of the other, as illustrated in Figure 3, but with two streams.
Figure 3. Multiple stream model migration between tooling releases
The number of differences per model between streams averaged 10 in the XDE stream set. After migration, the Rational Software Architect stream set showed an average of 10,000 differences per model. Obviously, because nothing else had changed, each model had almost 10,000 new (and quite superfluous) changes.
This customer's issue identified a critical need for a solution. We developed the Model ID Alignment tool in response.
In Figure 3, all models from Stream 1 are copied to Stream 2 and opened in the new tool, allowing the automated migration to take place. Each software configuration management (SCM) system provides this private working area for the new models in a slightly different way, but in all cases the models will be opened in the new tool and end up in a Version 2 "stream."
A variation on migration is the successive importing of a model from an older version of the software. The example shown in Figure 4 was encountered and solved on a customer site. A model is migrated to Rational Software Architect from Rational Rose software and then maintained in both tools while the overall migration is evaluated and then staged.
Figure 4. Re-import when maintaining models in different tools
Changes made in the Rational Rose stream are to be reimported into the Rational Software Architect stream. But this time, the changes from the incoming model must be merged into the Rational Software Architect version of the model that has changed. The fusion feature works well here, because user intervention will be necessary to figure out potential conflicts between changes based on each of these tools
The actual flow is simple:
- After importing the model, rename the model file and check out the existing version.
- Then combine models with the newly imported model as the source model and the checked-out model as the target. See the section about Rational Software Architect provides two methods to solve the general problem of models that have similar structures, yet have identities that are not aligned: model fusion and model ID alignment., which follows, for further discussion.
