Simplify UML
I found this interesting quote in Ivar Jacobson's blog entry "Taking the temperature of UML".
Still, UML has become complex and clumsy. For 80% of all software only 20% of UML is needed. However, it is not easy to find the subset of UML which we would call the “Essential” UML. We must make UML smarter to use.
Steve Cook, from Microsoft, an OMG member, has been leading a task force to discuss simplification of UML.
And in another article titled "Grady Booch on Design Patterns, OOP, and Coffee", Grady Booch responds to the question about developer hostility towards UML.
The most important artifact any development team produces is raw, running, naked code. Everything else is secondary or tertiary. However, that is not to say that these other things are inconsequential. Rather, our models, our processes, our design patterns help one to build the right thing at the right time for the right stakeholders.
Yet, while code is king, one must realize that it is also a servant, for it in the end must serve some constituency, deliver some measurable value. Just as I loathe architecture astronauts—people who have no skin in the game, people who are so divorced from the reality of executables that they melt in the sight of a line of code—I also loathe code bigots who are so blinded by their own prowess and tools that they lose sight of why or for whom they are toiling. Design for design's sake is meaningless; code for code's sake may be fun but it is also meaningless.
When asked his views on whether UML diagrams should be 'napkin' or highly semantically meaningful diagrams, Grady Booch responded:
When Jim, Ivar, and I began our journey that became manifest in the UML, we never intended it to become a programming language. I think that there's a fairly narrow domain for which model-driven development makes sense (and Ericsson is the classic example of value, for they use the UML deeply in the creation of all their cell base station equipment) but that we should return to the roots of the UML, which was to be a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system—in short, a graphical language to help reason about the design of a system as it unfolds. Most diagrams should be thrown away, but there are a few that should be preserved, and in all, one should only use a graphical notation for those things that cannot easily be reasoned about in code.
As I've also often said, the code is the truth, but it is not the whole truth, and there are things such as rationale, cross-cutting concerns, and patterns that cannot easily be recovered or seen from code.... These are the things for which a graphical notation adds value, and any such notation should be used only if it has predictive power or reasoning power (meaning, you can ask questions about it.
It will be interesting to get formal market analysis on usage patterns of UML in the industry.