Site Sponsor
Go WordPress
The Road ahead for UML by I. Jacobson and S. Cook
Ivar Jacobson and Steve Cook have written an article in Dr. Dobbs journal giving their view on the future of UML.
Basically, this article is a repetition of what Ivar already said a couple of months ago and can be summarized in one sentence: “For 80% of all software only 20% of UML is needed”. Of course, the difficult part is to agree on this 20% (which probably will be domain-dependent since different domains may require different UML subsets).
If you enjoyed this post you can subscribe to this Software Modeling blog and/or follow me on twitter or through the portal’s mailing list . AND if you really liked it help me pass it ON TO others by bookmarking AND sharing the post USING the links below:
My VIEW IS that structure, behaviour AND state dynamics ARE required FOR every application out there, AND those together ARE much MORE than 20%.
If most people do NOT cover those aspects IN their models, that does NOT mean UML does NOT need TO support that, it means that most people ARE creating anemic models, which has limited usefulness.
Part of the reduction can come from chopping some of the most “esoteric” diagrams but we should also reduce the variety of elements that can be specified in other diagrams. Yes all the applications need to contain static and dynamic elements but there are several static elements I’ve never used (e.g. qualified associations) AND that I’d not mind to lose in future versions of UML.
Think you had to develop software using only UML, no further elaboration on the generated code, in the true spirit of MDD. You are going to find that many things you never needed before are really essential. That has happened to me quite a lot.
Another possibility is that you will find that a UML construct is not precisely defined enough, so it cannot be used as is, you need to use some creative convention to get around that. That means that in some cases UML actually needs to “grow” a bit more (or gain more detail), to make its features really useful.
But I agree with you that it is hard to find a subset that won’t piss people off. I am ALL FOR pruning anything that cannot be mapped TO running software: use cases, collaboration AND sequence diagrams ARE high ON that list.
The ONLY path FOR reorganizing UML IN a way that does NOT disappoint CURRENT adopters IS TO break it up, find a small kernel (that won’t be useful to anyone as is), make it truly extensible in a sensible way (package merging does not qualify), and rebuild it again from the basic kernel.
You might argue that is pretty much what was done in UML 2.0, but I’d disagree. We need a single powerful yet usable extension mechanism that would be superior TO the package merging/profiles duo, one BOTH LANGUAGE designers AND practitioners can benefit FROM.
Cheers,
Rafael
http://alphasimple.com/blog
one option would be to decompose UML into a set of DSLs to define different aspects of the system. Designers could choose which DSLs to use (and compose) to model a specific system.
Agreed. Independently developed DSLs must be interoperable though. UML needs some sort of advanced aspect/mixin style composability. But again, package merging is not it.
Rafael
http://alphasimple.com/blog