UML and productivity

Replies to This Discussion

Permalink Reply by Juha-Pekka Tolvanen on November 9, 2009 at 7:45

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

• ▶ Reply

Permalink Reply by Steven Kelly on November 10, 2009 at 16:24

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.

• ▶ Reply

Permalink Reply by Scott Finnie on November 10, 2009 at 23:00

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...

• ▶ Reply

Permalink Reply by Scott Finnie on November 10, 2009 at 23:18

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.

• ▶ Reply

Permalink Reply by Scott Finnie on November 10, 2009 at 23:30

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.

• ▶ Reply

Permalink Reply by Juha-Pekka Tolvanen on November 11, 2009 at 15:37

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?

• ▶ Reply

Permalink Reply by Juha-Pekka Tolvanen on November 12, 2009 at 23:18

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.

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page