7.5 Bidirectionality

7.5 Bidirectionality

The last of the desired features of transformations, bidirectionality, or transformations that can work in both directions, has the lowest priority. Bidirectional transformations can be achieved in two ways:

  • Both transformations are performed according to one transformation definition.

  • Two transformation definitions are specified such that they are each other's inverse.

The first way is shown in Figure 7-1. Because of the difference in source and target language, it is very difficult to build a transformation definition that works two ways. An example is where we transform a statechart in a business model to a plain Java programming model. In our transformation, we might transform a state to a boolean typed attribute. It is generally not possible to regenerate the same statechart from a Java code model. There is no way to find from the Java code which attributes should be states in the business model. Even though the two models might be semantically equivalent, the abstractions from the business model are lost in the code model.

Figure 7-1. Bidirectional transformation


In the second way, it is very difficult to be sure that both transformation definitions are each other's inverse. Take, for example, the transformation of public to private attributes from section 2.5.1. We cannot prove that the second set of rules is the inverse of the first set of rules. We simply believe that they are. For more complex transformation definitions, it is more difficult to prove , and our beliefs are tested severely.

As we can see, it is very difficult to define bidirectional transformations. But there is a second reason for giving bidirectionality a low priority. If additional information is added to the target language, or if there is information in the source language that is not mapped to the target, bidirectionality is impossible to achieve. For example, when we transform a business model to a relational model, we only transform the structural information from the source model. All dynamic information in the source model is ignored. It is impossible to regenerate the complete business model from the relational model.

A third reason for giving bidirectionality a low priority is that complete bidirectional transformations between models is only possible if the expressive power of the source and target modeling language is identical. This means that the abstraction levels of both source and target model are equivalent. The fact that a PIM is at a higher abstraction level than a PSM is one of the essential characteristics for getting added value out of the usage of MDA. If bidirectional transformations imply that the source and target models, i.e., the PIM and PSM, are at the same abstraction level, this is not a very productive situation.

In fact, the added value of bidirectional transformations is visible in situations where the MDA process has failed, for example, where a system has been built and the PIM has been lost and must be regenerated. In the following sections bidirectionality is not considered to be a requirement of transformations.

MDA Explained. The Model Driven Architecture(c) Practice and Promise 2003
Project Leadership (The Project Management Essential Library)
EAN: 2147483647
Year: 2004
Pages: 118

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net