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.






4 Kommentare:
Nice article.
In 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.
What 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.
The 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!"
Exactly! 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.
Post a Comment