hide all comments


Which is primary, problem or solution?

September 24, 2007 17:24:00 +0300 (EEST)

The 5-10x productivity increases in Domain-Specific Modeling come from the combination of a number of factors. I think two of those factors contribute the most:

  1. the raise in the level of abstraction of the language
  2. the smooth mapping between concepts of the problem domain and concepts of the language

The "language" here is the Domain-Specific Modeling Language, contrasted with the earlier general-purpose programming language. Both languages allow products to be specified, and both can generate full products from those specifications.

The task when creating a DSM language is thus to achieve the raise in the level of abstraction away from the bits and bytes of the implementation, and to offer a smooth, impedance-free mapping between the problem domain and the language. For both of those, we need to focus on the problem domain (the domain expert view) not the solution domain (the implementation in code).

Interestingly, it's just as much work to build a DSM language focussing on the solution domain as it is to build one focussing on the problem domain. Similarly, the tool support needed to build DSM languages will be the same whichever way you build them. That's why it's a shame but not entirely unexpected to see people get the wrong end of the stick -- especially in an environment with a strong existing focus on code.

Let's look at a couple of other people's perspectives. First up, Microsoft's Jezz Santos:

If you understand the difference between problem domain and solution domain in software design, you will know that [software] factories are all about the solution domain. We are so far away from modeling problem domain and turning it into software just yet - forget it for now. It has proven impractical at this time, it is too big a step at this point, we need to evolve to that later.

If that really is the Microsoft party line then I'm seriously disappointed. Maybe Microsoft are "so far away" from a real raise in the level of abstraction, but others most certainly have proved that it's practical. Pushing out that kind of poor advice is a disservice to Microsoft's customers, dragging their modeling languages down to near the level of the code. Failing to raise the level of abstraction much was the key reason why Ordina only achieved a productivity increase of less than 20%, despite spending man-years on extending Microsoft's DSL Tools.

Maybe Microsoft are so focused on selling their platforms and frameworks that they are misled into thinking those are primary, and the customers' actual problems and needs are secondary? From a neutral point of view I'd have thought it would be self evident that problems come first, and solutions are dependent on the problems. There can be many different solutions, built with different technologies, that all solve the same problem. Only a technology vendor would take the technology as primary, and declare that all customer problems must be expressed in terms of that technology to be valid.

Let's move on to our second perspective, from Antoine Savelkoul [grammar corrected for clarity]

Bottom-Up Approach = Reverse Engineering = Wrong decisions?
I'm doing an investigation on business DSLs. For a proof-of-concept DSL I had to decide whether to apply the bottom-up or top-down approach. ... I made the choice to apply the top-down approach and not have a close look at the existing code before having defined the DSL. By talking to the domain expert I identified a number of customer needs which I would never have detected with the bottom-up approach. This is because a lot of the domain expert's knowledge and way of thinking couldn't possibly be recognized and restored to its original form from the code.

The analogy with reverse engineering is particularly telling. When you have the original developer around, you don't reverse engineer the code: you ask him to explain it to you. Similarly, when you have access to problem domain expertise, you don't try to reverse engineer the problem domain from the code. The code is already at least one step removed from the original, and reverse engineering adds another step: this is Chinese Whispers or the rumour mill, with all the attendant problems of lossiness and distortion.

UML is cited by many as an example of something that is not domain-specific. Microsoft were originally praised by many for not tying their DSL Tools down to UML. Yet even in 2004 the UML gurus recognised something that Microsoft seem not to have understood yet:

"the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts"
An MDA Manifesto, Grady Booch, Alan W. Brown, Sridhar Iyengar, James Rumbaugh, and Bran Selic, Business Process Trends/MDA Journal, May 2004

Note that I'm not saying you can't start from a framework as the source of your language concepts. That's one possible source, and not to be ruled out or ignored. However, the information there will be muddied by implementation details, concessions, historical factors and earlier mistakes. Why drink from the muddy pool downstream when you can go upstream to the clear spring it originally comes from?


Problem domain first

[Juha-Pekka] September 24, 2007 23:35:35 +0300 (EEST)

Few years ago we analyzed tens of cases from various domains to understand how our customers create modeling languages and generators. While both ways are possible, clearly the languages originating from the problem domain worked better. Like you wrote, abstraction is higher, complexity can be hidden and the benefits of automation are obvious. The various approaches to create domain-specific languages is published in the proceedings of the 4th OOPSLA workhsop on Domain-Specific Modeling. 

Wow - where to start?!

[Peter Bell] September 25, 2007 17:41:06 +0300 (EEST)

I am blown away by the Jezz Santos quote. I think everyone (Microsoft included) would admit that DSL tools is a 1.0 release missing some key, basic features like the ability to iterate in the generation phase ("for each business object create the following DAO", etc.), but I've been impressed by the quality of the team they pulled together to architect the product (and I know of the work around for the iterator, but I think the concept should be built into their meta-model).

The quote to me is the antithesis of Domain Specific Modeling and is the reason why so many projects fail when they don't abstract the modeling concerns sufficiently from the implementation concerns. I read the entire posting to see if there was a context to explain the quotation, but there wasn't. I must be missing something as I'd always considered the job of most business programming (even without explicit DSLs and code gen) was to raise the level of abstraction of the programming language to the problem space. Otherwise how can end users understand and ideally maintain their own business rules?

From an implementation perspective I've often found that a combination of bottom up and top down works well. I'll typically have a generator (or dynamic runtime interpreter) using top down domain concepts, but it'll usually speak to a framework that may have 2-4 layers of concepts built up using standard OO API design principles so my generated code is still very simple and readable - usually with one or a few lines per declarative statement added to each class file.