© CSXW 2011

Let us describe some transformation scenarios of interest at CSXW 2011 in slightly more detail. Thereby, we begin a comparison and characterization of transformation scenarios that should be continued at the workshop---as we aim at a corresponding ontology of specifically bidrectional transformations and generally coupled software transformations. The following discussion covers a broad range of scenarios within the general areas of software evolution and system implementation. The discussion also illustrates that the CSXW 2011 workshop is meant to bring together researchers from programming languages, model-driven engineering, data management, graph transformation, and others. The presentation groups scenarios by the relationship of interest between the source artifacts subject to changes or co-changes:

• conformance
• consistency
• source/view
• two-level mapping
  
• ...

 

Focus on conformance relationship

Consider relational schema evolution in database re-engineering: when the schema changes, the database instance has to be co-changed. Likewise, consider metamodel evolution in DSL development with model-driven engineering: when the metamodel changes, instances (say, models) have to be co-changed.

Both scenarios relate to software evolution.

Both scenarios are concerned with artifacts that are related to each other by a conformance relationship:

• an instance conforms to a schema;
• a model conforms to a metamodel;
• a value conforms to a type;
• etc.

 

Focus on a consistency relationship

Consider instead software modeling when it involves multiple models that need to be consistent with each other because of some overlapping model elements. For instance, a UML-based model may involve class and sequence diagrams where messages in the latter may be required to be covered by the former. Thus, when one of the models changes, the other model has to be co-changed.

Likewise, consider DSL development with model-driven engineering when multiple models cover different aspects of the DSL. For instance, the DSL specification may include a metamodel and a definition of a visual concrete syntax. When one of the models changes, the other model has to be co-changed. Likewise, too, consider the development of language processors such as compilers or re-engineering tools for programming languages where different syntaxes and intermediate representations are leveraged. When one syntax or representation format changes, the other syntaxes and formats have to be co-changed.

Commonalities at work:

• All these scenarios relate (again) to software evolution.
• All these scenarios are concerned with artifacts at a similar level of abstraction.
• The artifacts are related by a consistency relationship.

 

Focus on a source/view relationship

Consider instead the update-view problem in data management: when data is changed within the view, data has to be co-changed in the source (i.e., the actual relations, say, tables). Likewise, consider data conversion on strings or XML trees where a source must stay in sync with more programmer-friendly views: when a view changes, then data has to be co-changed in the source. These scenarios are concerned with system implementation and essentially data processing (as opposed to software evolution). The derivation of the view from the source is an interesting transformation by itself. In fact, these transformation scenarios are concerned with artifacts at a similar level of abstraction which are related by a transformation.

These scenarios are representatives of the well-established class of BX.

 

Focus on a two-level mapping

Consider instead XML data binding where an object model has to be derived from an XML schema (or vice versa) and functionality is needed both to serialize object graphs (in fact, object trees) as XML content and to de-serialize in the inverse direction. This scenario also goes by the name of O/X mapping. Likewise, consider O/R mapping or object persistence where relational schemas need to be related to object models and database instances need to be related to object graphs---both ways.

Arguably, such O/R/X mapping scenarios are (again) BX. However, these mapping scenarios are degenerated BX scenarios in that no non-injective functions are involved in an essential manner. It turns out though that there is another interesting dimension of coupling. That is, the definition of any such mapping essentially consists of two levels. Thus, there are two mappings such as the XML-schema-to-object-model mapping, and the XML-to-objects mapping. If either of the two mappings changes, the other mapping may need to be co-changed as well. Hence, the key challenge is to actually define mappings in a way that both levels are mapped consistently. The established research domain of data refinement has addressed this question traditionally, but nevertheless O/R/X mappings are nowhere perfectly understood and mastered---partly because of the two-level issue.

 

Beyond binary relationships

Consider instead the problem of grammar convergence in grammar engineering where different grammars are shown to be similar or equal on the grounds of grammar transformations that are also meaningful at the instance level (i.e., the parse-tree level, for example). Likewise, consider data integration in data management where multiple sources (say, database instances) must be integrated into a single instance: when a source changes, the integrated view must be co-changed. These scenarios combine some of the issues listed above, but there is the additional complexity of more than two artifacts to engage in a relationship.