The Problems with Using DSL Statements for Implementing Feature Modeling

The problem with using statements in horizontal DSLs for implementing SPL configurations is that it isn't a common approach so it makes it hard to take advantage of existing DSM tooling such as MetaEdit+ or openArchitectureWare. Both have great tooling for working with DSLs, but leveraging them within a SPL appears to require some trade offs . . .

Typically if I was to use MetaEdit or oAW for modeling, I'd describe a meta grammar for my various DSLs (business objects, views, controllers, validations, workflows, etc.). Then I'd start to create models, so if I wanted a shopping cart I'd describe the controller actions, views, business objects and the like that were required. I'd then create some kind of transformation or generation artifacts to turn my DSL statements into an output (usually either generated code or a serialized external DSL such as an XML file).

The problem with this as I pointed out before is that I need lots of shopping carts and most of them are the same, so I want some kind of feature modeling mechanism that allows me to say "I want this cart with these options" and that would generate the code/XML. That in itself would be a simple enough problem to solve. What makes it more difficult is that I want to allow customization at the DSL level.

Imagine checking the boxes to get a standard shopping cart described in fairly high level horizontal DSLs and then being able to tweak one of the standard views, add a new controller action or customize the validation rules for a given property - all in the DSL without having to drop down to 3gl code. This would allow for a really quick approach to getting a rough cut and then doing most of the customization within the DSLs.

Of course, even that isn't too hard a problem. You just use the feature modeling DSL to gen the input to the horizontal DSLs. So, for example, you write a generator that turns a given feature model into the XML describing the features in the DSLs and then load that into MetaEdit+ or oAW.

So, if that isn't a problem what is? Well, the problem comes in when you want to change your description of a given feature and apply that automagically to existing projects . . .

Let's say that I want to add a LastEdited property to the Order object for all shopping carts or change the name of the "title" property for the OrderItem object fro OrderItem.Title to OrderItem.Name. How would you apply those changes to the applications?

In our current system we have the concepts of essential, optional and custom DSL statements (metadata). For example, if you want to have a shopping cart, an OrderItem object is essential as is an OrderItem.Price property, but the OrderItem.Weight property isn't required unless you want to implement a weight based shipping mechanism. It is often used though, so it becomes optional metadata. If you sell Jewelry and want the number of beads per inch to be an OrderItem.BeadsPerInch property, that would probably be custom metadata as I doubt that many of our other clients would be interested in reusing that data.

Because of this distinction, we can easily add metadata to packages and re-merge metadata to re-create new versions of existing applications with no manual intervention. As with any kind of automated transformation, there are edge cases where (for example) we might add essential metadata that conflicted with custom metadata, rely on the new essential metadata and run into runtime typing issues, but for the vast majority of use cases our current approach allows for a pretty elegant model for supporting configuration changes over time by distinguishing the metadata generated by the configuration engine from the custom metadata while still deploying both to the same set of horizontal DSLs.

The main limitation with our approach is that we need to write our own tooling for creating and editing metadata as it isn't easily integrated with other tools.

I'm always a little concerned when I appear to be doing something different to most other smart people in a field. It usually means that I'm missing something, must use case is sufficiently different, or I'm ahead of the curve and just waiting for everyone else to catch up. All three have been true in the past - I just wish I had a better mechanism for distinguishing my brain farts from my more inspired choices, but I usually find that only time will tell . . .

Any thoughts?