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: 1787

Reply to This

Replies to This Discussion

(It seems I can't reply on Andreas' reply below, so I'm replying here.) Since Andriy is on vacation, I'm taking the liberty of trying to reply for him :)

The question what people and skills are required for MDx doesn't have that much impact. This is already a consequence of the statement that "MDE process is just a traditional development process with a few complications": the few complications have some impact and you'd need someone who knows (or is able to find out) how to deal with these. Obviously you need to be aware of the existence of the complications, but I think the sentiment is rather one of dreading complications too much than ignorance.

MDE = Model-Driven Engineering: to me that's the application of Model-Driven techniques (DSLs, code generation and of course (meta) modeling) to drive (parts of) a software development process. It's the pragmatic application that counts and as such (and in its simplest form) it can be viewed as the (somewhat rigorous) application of principles like DRY, Single-Source, SoC, etc. in a model-driven way, with the goal to improve the software development process.

Of course, as soon as non-devs start modeling the game changes a bit and you would need additional skills - not that these are adequately by any existing MDx methodology.

In that respect, MDx technology doesn't have to be all that different from your everyday dev technology: you could do code generation using Visio and VB.NET (if you really wanted that). Obviously, there are tools out there that do a much better job but that doesn't mean your whole project has to be "modelized" to the n-th degree before they can be used and MDx can become a game changer.

I don't know how to answer the question about what information is captured in models and what tooling you'd want for that, in detail. The generic answer is: whatever is required to make the software but no more.

Hi Meinte,

> ... people and skills are required for MDx doesn't have that much impact...

on an abstract level, we cannot decide. It's a matter of subjective sales and project experience. I'd be more than happy if I could share yours. 

We can enable people to decide by themselves, if we show: with tech X you can do Y and need to know Z, e.g.

> MDE = Model-Driven Engineering ... DSLs, code generation ...(meta) modeling
> ...what information is captured in models and what tooling...

I understood that Andriy is doing something more/else/diffent, more in the general direction of or something more "MDE (innovation) process" oriented.

> ... MDx technology doesn't have to be all that different from your everyday dev technology...

It doesn't have to - but it might very well be :)




> I'm not sure where you see the "traditional MDE development process"

Indeed there is no MDE development process in your diagram#1. I was referring to Meinte's steps 1-5. He was talking about a process to produce model-driven tools/infra (these are used to develop artifacts in diagram#1).


Speaking of the MDE process, in practice it often piggybacks a traditional development process. But these two processes build different systems (former - for developers; the latter - for business users) and have different life-cycles.


Meinte is right that traditional technologies can be used to develop model-driven infrastructure. However, this is suboptimal as we all know that traditional technologies do not deal well with increasing complexity and flexibility (I bet Meinte himself prefers to use proper MDx technology :)


>.. at present the majority of MDx projects operate rather precisely in the area shown.

Yes, agree..


> "A DSL which in a customer specific fashion creates something whatsoever *can* be a good, agile, and desirable solution - but the DSL attribute alone does not guarantee this by itself"

It is true. This is an extension of worst practice "visual programming with models". DSL does not replace information/knowledge analysis and proper structuring of them.


> So, let's be specific..

I will extend your diagram at later opportunity


> "One dimension is surely missing in the picture, which are concrete domain, process, task, trade, customer, or organisational unit specific model instances (or frameworks, or reference models). These have an inner architecture as well, and they are connected with and rely on the languages we use, and they are utterly interesing, too. Whether they deserve their own "language" or are just "model instances" is an interesing issue."


Actually, I think this is the dimension where most MDE professionals of domain-specific kind are spending most of their development.


> "who exactly (which roles) in which organisation is affected by which part of which new process?"

I think it depends entirely on where real value is created within an organization, not on the roles. Roles and processes are means to create the value.. A good information/knowledge analysis may have surpassing results.


> Can you explain what in your understanding is "MDx tech ... for the above work"?


An example of MDx tech in my work is MetaEdit+ or any other language workbench that allows to create modeling tools for traditional development/business processes. Sometimes these tools are bundled by vendors with DSLs for common types of artifacts (which are shown in your diagram).


> "I'd be interested in what information the models you describe capture, and what kind of tooling you'd wish for that."

These subjects are in pipeline for my blog.. Some information is available in the DSL tutorial, which can be found here.

I am not sure we should combine comparison aspects as then we will try to embrace the "unembraceable". I already counted four different things implicitly present in this thread:
- MDx Technology
- MDx Methodology
- Business domain/process
- MDE (Innovation) process
For the technology aspect, I've just posted a blog that describes measuring metamodel quality. This is something that I used a few times to quickly filter MDx tech. Do you see this as something useful in the comparison?

second reply@second post :)

> ...embrace...

Would it help to explain these issues on separate pages each? I would like that idea, and it would actually fit very well to the goal of the wiki (which is explaining business technology unbiased).

> ...measuring...

I browsed that "paper" (which is actually a book :*) ) and it answered my question what the authors mean by formal semantics specification.

a) yes

b) I would add "Business Technology"; i.e. the various types of models business users shall work with (and maybe relable Technology with IT Technology, while for sure both "Technologies" overlap)

Hmmm, it's been a busy summer - which caused me to miss this completely. I'll read to the discussion a.s.a.p., and will definitely have a look at your web site. Great initiative!

Andreas, I read through it all, and checked out the web site. Although your goal seems clear, the discussion here could do with a summary - which could then be included in the site. 


Have you also looked at the comparison we made of the LWC tools, as compiled by Pedro Molina? I'm still looking for a Ning developer to help me integrate that here at the MDSN site, but for now, you can check it out here:

Hi Angelo,

thank you for the link and the hint for doing a summary, you're right about it. I hesitated a little with summarising because I felt we need a little more clarifying discussion here, but partially that's also been just an excuse for myself since I didn't found the time yet.

Of course I noticed the various postings concerning LWC and I studied some of the results, thanks for the valuable feature matrix link, which I haven't seen yet. Is it a permanent page I can refer to from the wiki?

(just in case you're interested and can afford to spend the time: you can help editing the wiki, actually we'd appreciate that very much)

The link on the site is semi-permanent, I'm migrating the site to WikiMedia at some point in the near future. 

I'll see if I can find time to add something on the Wiki.




© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service