DSM/SPL: Concrete Syntaxes for Model Reuse

However, when you start to look at support for re-use of models and model statements, none of the existing tools are designed out of the box to support efficient model reuse across projects. This posting will look at various concrete syntaxes for model storage and editing and their suitability for efficient model and model statement reuse . . .

The biggest issue with most of the existing tools is the lack of in-built support for model reuse/configuration/customization. Generally you're working with models directly and there are no built in constructs for feature modeling and configuration/customization of your models. This is *not* to say you can't use the DSM tools for SPL's - you can. But you've just got to kind of build it yourself by building a language for your feature model and then hooking that into your re-usable model assets in an intelligent way. However, instead of looking at specific tools, I want to look at some general approaches to storing models and how they work for model reuse.

One of the most common storage mechanisms for model data is XML. It's easily parsable, you get a basic meta-metamodel with a type system and constraints for free (most people chose XSD - XML Schemas) and it's widely shareable and fairly easily transformable. In fact, most tools that don't store their models in XML still have some kind of serialization option to export or import models from some kind of XML such as XMI in the Eclipse Modeling Framework. It's also fairly supportive of model statement reuse. It requires you to know how to walk the tree to your model statements (you need to go to the User entity to find its Properties), but then you could use something like XPath to select the subset of elements you wanted and/or XSLT to apply model transformations to add and remove properties from a base model to implement a custom model.

In general textual DSLs (excluding those using XML) are harder to work with/reuse. There is no requirement for each model statement to be on an individual line, so applying transformations to your models in their native textual format to reuse subsets of models is not easy. However, the solution with most textual DSLs is to load them into a tool that'll construct an AST that you can then apply transformations to using Model to Model (M2M) transformations. For example, if you're using something like Xtext to build tooling for your languages, the models themselves will be simple text files. Working directly with those would be difficult, but openArchitectureWare provides you with the Xtend transformation language which allows you to apply transformations to your models and then to output the results.

Another approach is to store the model AST directly. MetaEdit+ and MPS both have their own internal stores for representing the models directly. Again such an approach lends itself to some form of model transformation, perhaps walking your model and outputing some kind of representation of an appropriate subset/superset of the model statements to create a new model which you could then work on for a specific project being created within your software product line. I'll admit to not being as familiar as I should be with such tools, but they definitely offer an interesting approach.

One approach that I don't hear discussed very much at DSM conferences is to use a database as a concrete store for models. It obviously makes it very easy to work with model statements as each statement is a record in a table. You need a fair bit of tooling around a databased solution to avoid it being unwieldy, but it is particularly suitable for granular reuse of model elements as it's just a matter of selecting the records needed for a given project using joins. I'm not sure yet whether this is a better or worse approach than the M2M transforms using (say) oAW and I'm not clear about the use cases where each one would excel. However, it does have the benefits of being easier to pick up than M2M transforms (more developers are familiar with database queries than with model transformation languages) and the additional benefit that if you're building web based applications that store information in a database, you can reuse your same core tooling all the way from the meta-metamodel down through the metamodels to the models to the data that resides within the model as they are all just storing information in related tables, generating schemas for the next level down based on the structure of the meta-level.

The challenge with databased repositories (which are really just a special case of storing the AST where the AST is defined in terms of tables with relationships) is that you have to look at and solve all the standard DSM problems - multiple users, multiple repositories, versioning, schema evolution, etc. The only good news is that if you do so, you're also solving them right down to the end user data level so the same tool you build for model evolution can also be used to transform the actual business data in your application that needs to be transformed as part of the model evolution.

My current system is based on a databased repository and I think I'm going to continue to work with it to see what I can come up with in terms of elegant solutions to all of the usual scalability problems. If nothing else it'll make for a couple of interesting papers, and because I'm basing my meta-metamodel on ecore, I could easily port to a EMF based solution if I found the approach was becoming unwieldy.

Anyone got any opinions/thoughts on the relative strengths/weaknesses of building a SPL on EMF as opposed to using a databased repository?