“If UML is the answer, not many people are asking the question” -Jim Fawcette
I have mixed feelings about a statement like that.
On one hand, Visual Studio Team System is going to break through software development with Microsoft technologies in new and exciting directions; I am eager to embrace large-scale development projects with it, one reason is that I wholehearted believe Microsoft is headed to a very good direction with tools, processes and techniques for software design.
On the other hand, there is a notion about “modeling” is just about making nice UML drawings or over-elaborate software structures making convoluted, intricate and complex ‘designs’ and ‘architectures’ without reflecting about how design decisions permeate into source code and vice versa; so UML is usually associated with such unrealistic design style, and that is a pity.
Unified Modeling Language 1.5 combines important concepts applied by old software design practitioners for many years and condensed in a homogeneous approach; talking the concepts is fruitful, thinking in UML terms is worthy, throwing UML diagrams as “models” or “designs” is futile.
As of UML 2.0, I don’t know, we’ll see. It has too many tests to pass; it is too much abstraction to grasp without a closed-loop feedback mechanism for design control. The same problem occurs with current mainstream UML usage, that notion about a model is a static representation of structure; I feel somehow embarrassed to talk with practitioners of designs professions like engineering or architecture and say “we also do models” or “we also do architecture”.
I am glad to see Microsoft taking a sensible approach to software development tools, processes and techniques, leading the way in our industry; sure, there will be misuse and abuse of our tools just like UML and many others but that seems to be the way things are in our industry for the time being.
Update: I found the following article to be a landmark in Microsoft history:
Visual Studio 2005 Team System Modeling Strategy and FAQ