There is a lot of information available about how to do UML (Unified Modeling Language) analysis but most of it is written for systems analysts. Here's an article about UML that is written for programmers.
A Short History of UML
UML is one of the most widely used analysis tools in software engineering. A model is an abstraction of a system - a way of completing describing a system so it can be studied and - more importantly for the programmer - coded.
The "Unified" part of the title is a hard-earned result of the Method Wars of the 1990's. Back then, serious professionals in the modeling business were almost at each other's throats arguing about, if you can believe it, the shapes that should be used in models. For example, a red-hot issue at the time was whether to use "clouds" in modeling diagrams. The "wars" were finally over when three of the top warriors ("The Three Amigos") agreed to support just one method that they called UML. Today, UML has been formalized as a written standard administered by the Object Management Group (OMG).
It's possible for programs to be actually coded by computers using UML (and other) specifications as input. This "automated development" is called CASE or Computer Aided Systems Engineering. The use of analysis tools for computer generated program code is often called "lower CASE". Computer aided analysis that is used by human programmers is called "upper CASE".
Microsoft, once a big UML supporter, is now sort of lukewarm about it. They got a lot less enthusiastic about UML at about the same time that IBM purchased the leading UML software company, Rational Software.
You can read a very complete statement of Microsoft's position on UML at their site: Visual Studio 2005 Team System Modeling Strategy and FAQ. About the only thing they fail to mention is IBM's purchase of Rational. According to Microsoft, they only have proprietary modeling software because UML just doesn't do the job well enough. Yeah, right.
UML is still the best "vendor neutral" modeling methodology. Even Microsoft supports importing UML into their proprietary modeling software. UML remains, for better or worse, the common language of systems analysis.
What's Wrong With UML?
Microsoft states that, "... for whatever reasons, the existence of UML and UML-based tools has not significantly changed the way developers build applications. Nor has it significantly contributed to developer productivity."
That's a fair criticism. You can spend an entire career as a programmer and never use UML, or any structured modeling system. Few programmers ever try to use UML as a starting point for the development of their objects.
Part of the reason is that most of UML just doesn't apply to coders because it describes whole systems rather than individual programs. The emphasis is on structure and behavior over an entire system and between the system and outside "actors" rather than the logic internal to one program. And "one program" is usually the focus for your average programmer. ("Oh MAN! My program crashed AGAIN!!")
Another big problem is that the terms and definitions used by UML just aren't the same as the ones used in VB.NET or Visual Studio. Terms that are the same can have different definitions and at best, are difficult to make sense of. For example, in UML 2.0, a "component" is:
"A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics)."
I'm frankly not sure if that's what a component is in .NET or not.
Microsoft states that UML is used more as documentation for code that has already been developed than it is as a modeling and analysis tool. And that is not the way it should be. If houses were built that way, then builders would hammer something together and when it was done, the architect would come along and draw plans for it. (Mainly to make it easier to tear down walls and fix plumbing that doesn't quite work yet. Does that remind you of some systems you have worked on?)
UML is an important topic for even coders to know about, however. For one thing, those geeky systems analysts use it a lot. You have to know when to turn your ears on and actually listen. (Non-programmers reading this who think programmers are excessively geeky should just run and hide from systems analysts.)
Even though open war between modeling authorities has ceased, few of them draw their diagrams exactly the same way and there's still a big role for "interpretation" in UML. These differences are another problem for your average coder in using UML. More than likely, if you are handed a UML specification, you will probably need to get the original systems analyst to explain parts of it to you.
On the next page, we look at the 13 different diagrams defined in the UML 2.0 standard.
