The Model Driven Software Network

Raise your level of abstraction

In various recent discussions (Tool for mdd, feedback on Fenomen, CG2011 fishbowl session, LWC 2011 etc.), attempts were made or at least the question was raised to compare different MDx approaches.

It seems, at present, we have a few rather different ideas of what MDx technology is, or should be. Far too often we compare apples and oranges.

For comparison, at least we should distinguish the following aspects:

- How do you interact with your model?
(graphical, textual, guided by a tool, validation)

- What do you model?
(level of abstraction, amount of models, completeness)

- What do you get "out of the box"?
(ranging from: complete domain specific business solution, up to: raw technical model to code transformations)

- What do you create?
(artefacts, completeness, level of abstraction of artefacts etc.)

- What can be modified, and how?
  (the answer to this question must be a really lengthy one and goes to the heart of MDx)

Related to the last question is, e.g.:

- How does your transformation chain look like?
(one stage, MDA, interpretation, something else/more/less)

All these questions can't be answered simply "yes/no" (except in marketing brochures, where of course all solutions are business oriented, totally complete and absolutely felxible).

For a different context, I was preparing an overview of MDx technologies. It's work-in-progress, but I thought it might be interesting to present it here in this early stage. The link is

The diagram shows the area of models and artefacts in MDx context. From left to right it goes through abstraction levels from business to software. The other axis corresponds vaguely to multi tier software leves (UI, BL, DB).

The purpose of the diagram is to be able to draw different approaches into it, and allowing a comparison of what each approach actually does in the area.

If you like, you can help improving that overview (your contributions will be save since it will be under a creative commons license). You can also help editing the diagram itself via an integrated browser-based svg-editor.

I'd appreciate your comments, either here at MDSN or in the wiki.



Views: 1788

Reply to This

Replies to This Discussion

Andreas, this is a much needed initiative as most tool comparisons are indeed like that among apples and oranges.


I am interested in the question you posed as well. In the past, I've done a few tool reviews, one of which (MetaEdit+) can be found on my blog ( Currently I am looking at the comparison problem from a different angle than you.. 


If I understood well, you are exploring different application/domain areas as basis for comparison. It seems to me that such basis is meaningful only for tech with (partially) fixed method (i.e. languages and transformation), which is more inherent to traditional CASE tools (and not MD tech). Totally agree about the other classifications orthonogal to application/domain areas (e.g. text/graphical/combined concrete syntax paradigm).

Hi Andriy,


Thanks for your feedback!


Let me explain the idea of the comparison diagram a little better. Obviously, MDx (and related) technologies are ultimately used to transform nice, business-user-friendly, fool-proof specifications into working runtime systems. There are many different approaches to support this complex transformation, on different levels, like e.g. the model instance/model/meta-model axis etc.


The axes in the diagram should not be taken as a formal 2-dimensional space, the diagram is more like a mindmap, and the axes showing coarse directions.


Actually, the problem you mention is already the same with the graphical/textual axis: the distinction between graphical/tectual can be made for each and every model, independent of how technical or how business oriented the described information is. E.g., a graphical UI designer can be more technical than a business oriented textual language.


Now, the diagram shall visualize the various tasks the technologies have to accomplish, i.e. which information is represented in which language/model/artefacts, and how it is transformed into a different kind of information or different representation or final artefact etc.


The different approaches and tools therefore have to be represented differently in the diagram. E.g. MDA has a certain idea of a 2-step transformation; CASE has a rather simple idea of a single-step transformation. Both correspond to specific areas. Universal Language-Workbench-like-Tools do neither provide nor predetermine a specific transformation chain, nevertheless, they finally serve a certain purpose in this area. Depending on the tool, such a purpose might be to help creating and maintaining meta-models and transformations; both are artefacts, which can visualized. Additionally, they implement certain tool classes, like M2M, M2T etc.


What I want to achieve is a clear picture of what goes on in this MDx area, and how the tools help to do this. It shall show what each tool does and what it not does, what is provided and defined by the approaches and what not, and what types of information one has to deal with (abstraction level).


Surely some tools can be used for a large number of purposes, we ourselves have a technology called "OCP" which is used for object aggregation, and which can be used for model transformations, model parsing, UI widget aggregation etc. But the focus of the diagram should somehow be "business usage scenarious", and not "everything that can be done with MDx tools". On the other hand, your point is definitely one we should reason about carefully.


I would be interested in the various properties you do consider as important in that comparison. I've read your blog post, so I think I got an idea.

Andreas, thank you for the detailed explanations. I think that such description is definitely useful, as it communicates better to customers what the tool can do out of the box. However, IMO such comparison needs to be extended (don't know how yet..) as it does not help to distinguish fixed CASE tools from language workbenches.

Well, it does, but it only shows the disadvantages of LWBs (naked technology vs. "complete" old-style case tool) and not the advantages (flexibility/agility vs. strictness and closedness), which is certainly not the purpose of the comparison.


So, you've got a point. I added another diagram to the page, showing something like a "MDx multi-tier architecture". It's a first draft, I'm not really satisfied yet with the boundary between the MDx "application provisioning" part (the left side) and the "application operation" part (right side). But this is an intrinsic problem, since this boundary actually is anything but sharp and moving over time.


The relation between both diagrams is, that they are orthogonal views, and the first one is simply a birds eye view of the middle tiers (domain & semantics).

I would also like and want a diagram which clearly communicates the essence, process and value of MDx.

Clearly there is a need for a comparison framework. It is also clear that there are different interests in such a framework. Can we make a list of concerned users/roles and their interests? 


Andreas is interested in out of box support for common engineering abstractions and methods, probably meant for IT professionals. My interest is quality and efficiency of adapting/customizing MD tech, which is concern of organizations adopting MDx. Meinte, can you explain your interest?

Well, it's my experience that (1) we, as a MDx community, are still struggling to get our point (why do MDx at all) across -both to technical peers and managers alike- and (2) the way in which we apply MDx varies so much that I don't expect a technical/process-oriented diagram to capture it all and help with (1).


Apart from that, the discussion as-is is interesting enough in itself and I'm not trying to detract from it.

Meinte, I completely agree with both points you make. The first issue is something that deserves a separate attention. As for the MDx, while it may have uncountable applications (your point as well I guess), there are countable properties that make such variety possible, which makes these properties interesting ingredients of comparison. But ultimately a comparison should solve a real problem..

In fact, I'd say the application of MDx should solve a real problem, period!


I guess I'm missing (the statement) a concrete goal for doing MDx in this discussion and I think having that would make the comparison more realistic as it provides properties that are actually useful outside of a completely technical and intrinsic overview of MDx and some of these may even be measurable.

The problem is, there is no single goal of MDx technology, instead there is a variety of claims, which is why MDx comparison is often like apples & oranges.


E.g., a goal of MDx might be to make software production faster and more reliable. Another goal might be to enable non-technical business people to get a grip on their systems. And yet another goal might be to make software production more agile.


Depending on the goal, different soltions will be required. Their ingredients have an overlap, but they are not identical. All are labeled "MDx".


Necessarily, an overview must touch business relevant parts as well as IT relevant parts. Don't be confused by the mixture of both in diagram #1 ! The artefacts which are placed on the left are as technical as paper & pencil: these are the tools business users will have to work with, which they need to understand, become familiar with. Their quality, abstraction level, accessability is very relevant to them.

Hi Andriy,

I think it's a good idea to make some kind of usage list to approach the MDx topic as broad as possible, since my goal is to produce a complete overview.

However you seem to have misunderstood my position. I'm not generally advocating "out-of-the-box" over any other approach, I just took the position of the devil's advocate in the example you gave (case vs. lwb). See my initial posting for a list of issues I consider as important - this list includes lwb issues very well.

Interesting in the context of a classification and an overview of MDx is the following. If I understand your above statement correct, it contains two claims:

1. MDx is only that: LWB-like tooling for editing models + transformations
  (excluding e.g. tools which simply based on a model operate an application, without any transformation)

2. the popular marketing-pattern "We-Do-Business,You-Do-Tech-Stuff"

If I got you wrong, please correct me. Howsoever, both claims can be found elsewhere and are worth a comment.

First, what is and what is not MDx is a matter of ongoing debate, of definition, and of marketing activities. At present, I'd favor a rather broad definition, covering all uses of the term. I do not think this is difficult.

Second, the Business-vs.-IT position is exactly a position I want to overcome. I consider this situation at the interscetion of the two domains (see e.g., 2nd paragraph) as a costly (nevertheless extremely widespread) mindset.

Both managers as well as IT experts are IMHO generally skilled people, interested in doing a good job and capable of doing it, within their respective range of possibilities (exceptions, as usual, prove the rule).

That said, I think next to all of the approaches used in MDx (and elsewhere) provide some business value, finally. I want to show how the various approaches work, how they possibly interact, as impartial as possible, and which benefits they provide for business.

To pick up your examples, we can make the following list of MDx approaches, as they are presented by the respective proponents/vendors:

- "Tools for business people", i.e. the claim is "Business can model, the rest
is performed automatically"

- "MDx Tooling", i.e. LWB-like IDEs, emphasizing agility

- "Fully Model Driven" solutions, the claim is "really the whole application is created, no need for coding"

This list shall not be a rating, it just shall summarize the various claims. Are these the major types of MDx approaches? Any missing?

I would hate to be able to choose exactly one of these three approaches in all situations and I don't think they actual oppose each other - they're fairly orthogonal, even.

E.g., I think business modeling (or dev-assisted business modeling through business-readable models) is a very promising proposition. But we need good LWBs for that, otherwise we can never hope to achieve the level of user experience we require for that in a productive fashion.

And no matter how good our modeling is, chances are that not the whole application can be modeled. Often, this is because of a requirement that's hard or uncomfortable to model anyway. It doesn't hurt to introduce some "non-generated hook" into the modeling language, as long as you make sure it doesn't open the door for all kinds of exceptional demons - but that's an engineering problem whether you're using MDx or not.

If we step back a little and try to formulate a goal and quite generic process of how to "do"/introduce/evolve MDx in real-life project situations, the comparison would become much more valuable, IMHO.




© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service