The Model Driven Software Network

Raise your level of abstraction

Last October 7, Steven Kelly, member of this network, pointed to a research on UML productivity, made by W. J Dzidek, E. Arisholm and L.C. Briand, which shows not so much benefits between a UML conducted project and the same project developed in "pure java".
Do you agree in such a poor performance with UML? There are bad assumptions in that research? That comparation afects all UML, all model based development?
Productivity is probably the most expected profit when modelling. It implies that there is no changes following UML?
You can see Steven´s note at http://www.metacase.com/blogs/stevek/blogView?showComments=true&...
The research available at http://www.ipd.uka.de/Tichy/uploads/folien/149/DzidekArisholmBriand...

Views: 677

Reply to This

Replies to This Discussion

Fully agree with Scott on the importance of reference implementations. When inspecting the list of failures I would like to add XMI there too.

The really sad thing is that OMG "standardization" process also tends to include into the standards things that are not even ever used in practice. No wonder if they fail then.

IMHO: the time to standardize comes when we know already well enough which approaches work and can define a reference implementation.

Juha-Pekka
Maybe XMI is getting a bit off-topic, but if you want to know why I have a low opinion of it, it's simply because that's what others' experiences and research tell me. See e.g. my blog entry, XMI still a failure. XMI[DI] was even worse last time I looked: 10KB for a single class with no attributes or operations is kind of excessive.

I suppose the right attitude in these cases isn't just to say whether we like XMI or not, but to compare it with other similar things. I find GXL much better, although it too is not seeing so much new work.
If XMI is a success (and the jury is still out for me) it's a success /despite/ the OMG's approach, not because of it.

What was needed was a true, unambiguous interchange mechanism to allow passing of models between tools. What the OMG delivered was a very "clever" mapping from MOF, the result of which was no practically usable interchange standard - your XMI was different from mine. (I know of one commercial tool that can't import it's own exported XMI!).

Back to my point about reference implementations...
Vlad said:

"DSL for me is ugly !! You don't have any graphical specification, your model is generated using transformation layers e.g certainly EMF) and makes it proprietary and your code generation is the worth I have ever seen."

I assume you're talking about MetaEdit here - if not apologies for misunderstanding. But if so, that statement is misguided. MetaEdit does have a 'graphical specification' (and indeed you can choose to use the UML notation if you wish). Don't understand the comment about 'transformation layers'. As for cg being the "worst you've ever seen", well that all comes down to what you've looked at :-). I know I've looked at a lot worse than MetaEdit's (xslt anyone?).

I personally still find XMI very ungainly and difficult to work with (and others seem to be the same - e.g OpenArchitectureWare has a filter for creating a more usable metamodel population from XMI on which to execute transforms).

However, it's encouraging that you've managed to have some success with XMI and related tools on the eclipse platform. Shows the value of a reference implementation ... :-)

- Scott.

PS: For the record, I have no affiliation to MetaEdit.
That depends on your definition of 'failed'. UML has without doubt succeeded in establishing a defacto graphical syntax for some useful, general purpose modelling (sub)languages. That's to its credit.

But it has not been successful in delivering a general improvement in productivity. It hasn't allowed us to build and maintain software at a higher level of abstraction. It has not permeated the industry as a core element in the development tool chain.

On that basis it hasn't moved the industry forward in the way that, for example, C (and the C compiler) did.
What in the near future would be different than what we have already seen tried with UML? What - after 14 years of UML - would finally show productivity gains?
What? UML has had problems? And only now you tell that. Do you know if the coming versions 2.3 and 2.4 will work too? Will XMI work among tools and among the UML versions too? Let’s hope the voting in OMG goes well...

Jokes aside, I fully agree that tool support is important, and naturally tools should be stable too, but still I can’t see the type of UML tool functionality that would bring improved productivity. Time will tell and if things don't work as expected there is always room for newer UML version ;-) Still the challenge to build "one size fits all" language will become even more difficult since both technology space and domains where we apply software are getting bigger.

RSS

Badge

Loading…

© 2014   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service