The following link points to an interesting article (in German):
Groovy-DSLs mit Eclipse-GMF visualisieren
The article perfectly shows some of the issues I have with the current state of visual modeling and MDSD.
The first part of the article is about implementing a domain concept. This is directly connected to the business problem which should be solved by the software at hand.
The second part of the article is about making the solution of the first part accessible for visual modeling.
I did quite easily understand the first part. The second part however seems a lot like rocket science to me (or some secret ancient ritual). There are a lot of steps and different concepts involved (code, configuration, libraries, guis, wizards, repetitive reflection of the actual domain concept, mapping ...).
While I feel confident, that I learned something from the first part (creating a simple textual DSL with Groovy Builder), I do not have the feeling that I learned something useful from the second part, except that it is very complicated to use GMF...
In my opinion, as long as setting up (and maintaining) visual modeling for a certain concept is so much more complicated than the underlying concept itself, visual modeling hardly pays off!
You really have to evaluate costs versus benefits. And in my experience this is almost never done properly.
In the given article: What is the real benefit of visually modeling the process-chain?
Who is the target? Who will be using the visual modeling capabilities?
Are stake holders really able and willing to grasp the visual models? Or are you still going to communicate with them by Visio and Word?
If it is not for the stakeholders, do developers really like to work with the visual models, or is the simple textual DSL much more preferred by them (easier handling with current tools (refactoring, diffing, versioning ...))?
If you think about these questions, is the effort put into the infrastructure really worth it? The article says itself:
Indeed the learning curve [of GMF] is very steep. [...] To gain a better understanding there is often no other way than explore the GMF-Code with the help of a debugger.
This quote alone would rise a big questionmark if I were the project leader of a project that is actually supposed to provide business value...
In my opinion visual modeling is vastly overrated, and especially in the current state is hardly worth the effort.
In my experience any large-scale modeling efforts often turn very fast into a completely disconnected reality-loop. People are wasting a lot of effort just to conquer the accidental complexity that is introduced by the modeling requirement. The actual business requirement then comes only at second priority.
The metaphor that comes to my mind is this:
At the beginning you have a business goal, that is like the requirement to cross a river. But once you jumped into the river, you notice, that you vastly underestimated the current.
From now on you are fully occupied to keep your head over the water. Reaching the other side (not to mention at the specified spot) is of no priority at all any more.
Nice article.
ReplyDeleteIn the other hand I would ask: "textual modeling: is it worth it?"
I think about xText. xText is a nice textual modeling tool. You can create a DSL and models, based on your own DSL. It will be transformed later in a Ecore model, where it can be used for MDSD.
The problem on xText is, that (because it's so easy) for every problem domain, a new "language" is created. This also raises complexity and will result in harder maintenance.
I think, the approach to embed a DSL into a language (like the Groovy DSL) is a nice way for textual modeling.
I didn't understand the discussion, maybe for lack of experience with visual design.
ReplyDeleteWhat brought me here, and what I like, is the photo at the beginning. Keep up the good work, and do you happen to have her email address handy?
My professional (academic) research currently involves visual modelling. It is interesting to see the opinion of a non-supporter of visual modelling, as I usually talk to fellow supporters of this paradigm.
ReplyDeleteThe question you ask "is it worth it?" is indeed essential. It turns out that this is not the case for the article you're blogging about (I couldn't verify this however, as I don't speak German).
However, there are many more mature solutions to this problem. Take for example the tool "AToM^3" we developed in our research group (this is a prototype, so expect no fancy graphics - it's the underlying proof of concept that is very powerful). It is extremely easy to create visual models in AToM^3. Moreover, new visual languages can be constructed within tens of minutes from scratch. A modelling environment (i.e. an editor) for your new language is created automatically. Also, a "meaning" can be given to your new language by modelling tools for analysis, translation to another formalism, code generation, simulation...
We tested this in a master's course, where students managed to create languages, models and transformations for translation and simulation within hours. These students had no previous knowledge of the tool, not even of the model-driven engineering (or as you call it: MDSD) paradigm!
Useful links:
AToM^3: http://atom3.cs.mcgill.ca/ (look for the "basic" tutorial at the bottom of the screen for a quick overview of the tools capabilities)
Paper about the masters course: http://is.tm.tue.nl/staff/pvgorp/pro/phd/VanGorp2007MoDELSedsymp.pdf
I hope this convinces you of the capabilities of other approaches in visual modelling.
Cheers,
Bart
"it is very complicated to use GMF. In my opinion, as long as setting up (and maintaining) visual modeling for a certain concept is so much more complicated than the underlying concept itself, visual modeling hardly pays off!"
ReplyDeleteExactly! However, not all tools suffer from GMF's problems - or make their users suffer like GMF. Maybe you ought to look at some other tools? I think you'll find most successful graphical DSL cases have used our MetaEdit+.
A recent article agrees with you that there's no point building a DSL (graphical or otherwise) if it takes more time to build than it will save in use. In the case reported in that article, Polar found that building a normal product by hand took 23 days; thinking up, building and testing the DSM language and generators took 7.5 days; and building a normal product with the DSM language took 2.3 days.
So even for the first product, including the time to build the DSL, they were over twice as fast as if they'd just hand-coded. For subsequent products they'd expect to be 10 times as fast.
Of course that's just one case: for more evidence, check out other guru's and user's opinions about MetaEdit+, the five detailed cases in our DSM book
, or the lists of cases and articles on the independent DSM Forum.
Great post. It's really difficult to find posts/articles about MDA in a realistic way and with a pragmatic view of things.
ReplyDeleteWell, i've been working with CodeGeneration and later with MDA/MDD for a few years now.
What i learned while developing software in general its this: When you have two things that are good and complement each other... you got to support BOTH! :D
In this case particularly, i'm talking about Textual and Graphical model edition.
There are a lot of tools that do this, for example: Source and Code view editing ASPX pages in Visual Studio.
The difficulty to get there (enable textual and graphical support) for MDA and models edition its that the MDA tools mostly don't take any advantage of the MDA concept itself.
I think you can apply the MDD/MDA concept on any level, even on the tool that supports your MDA practice. EMF and XText do this in a certain way, you describe your language or your grammar in a DSL(read it model) and they the tool generate support classes for you to work with your models. But i still don't think they are there yet.
The other thing is, i agree with MDA mixed custom DSL's as the right way to go, and not only the UML/XMI approach that some tools try to enforce. When you have your custom language, models are easier to write and edit, they just fell more natural.
Trying to encorage and spread MDA in an easy way, i started this:
http://m4n1.codeplex.com/
I believe MDA its the next programming paradigm, so all my efforts now are directed to this.