As the saying goes, a picture is worth a thousand words. Does that mean a class diagram is worth a thousand lines of code?
Don’t answer that just yet…I bet you’ve had a bad experience with modeling tools in the past.
Confessions of an ivory tower architect
Now you may have used a modeling tool in the past, or been involved in a project where some SOA-preaching, RUP-spouting, ivory-tower architect tried to drown you in UML diagrams. In years gone by, we (being the SOA-preaching, RUP-spouting, ivory-tower architects) would plead with the Project Manager to buy us a real modeling tool such as Enterprise Architect. “Please sir, it’s only $199, and I have this 10% discount code that a friend of my friend got from TechEd.”
Invariably the Project Manager would say “I’m sorry, I spent the tools budget on buying this second-hand PC from eBay so that you could have one of those continuous integration servers you’ve been harping on about.” He points to a dusty P-II sitting on the floor. “Anyway,” he says, “My Project Manager buddy says that we’ve got a perfectly good modeling tool in MSDN called Visio.”
So we sigh and resign ourselves to the fact that we will be producing UML documentation at the start of the project that will quickly become inaccurate, misleading, and even downright dangerous to read as the coding progresses. There’s just no way it can possibly be kept up to date, especially since we’ll be wasting so much of our time trying to keep that damn continuous integration server up and running!
Even if we do get access to Enterprise Architect with its nifty Forward and Reverse Code Engineering feature, us architects will be constantly trying to play catch-up with the developers as the code quickly evolves. In the end we’ll probably decide that it’s too much work and we’ll just come back to it at the end of the project. Of course by the time the project is finished, 7 months late and way over budget, we’ll be so happy to see the end of it that we won’t want to spend another nanosecond of our time trying to get the documentation back up to scratch.
Isn’t that the way it goes down on every development project you’ve been involved in?
The code is the model, and the model is the code
The real problem here of course, is that in most modeling tools, the model and the code are two separate entities. It doesn’t matter how sophisticated a tool is at interpreting and generating code, you will eventually run into problems if the code and model are separate.
Solving this issue has given the Visual Studio Class Designer a trump card. The functions that it provides are somewhat limited when compared to other tools, however that’s not too surprising given it’s free (well not actually free, but included with Visual Studio). However the fact that the model is simply an alternate view of the source code immediately gives the Class Designer an edge over other external modeling tools.
Of the developers, by the developers, for the developers
The other key advantage of the Class Designer is that it’s right there in Visual Studio, even Standard Edition. You don’t need to have forked out the big bucks for Team System. As an unappreciated developer, who had to promise your boss naming rights to your first-born child just so you could get a second monitor, you don’t have to spend time trying to coming up with a plausible business case to purchase a modeling tool.
That’s one of the great things about Visual Studio. With each new edition comes new functionality that we previously had to find some money for, or try to locate a free equivalent, or simply went without. Tools that were previously only within the domain of the architect are now available for all developers.
Now if only Microsoft could move some of the other design tools into the Professional Edition, or drop the price of Team System.
Getting the most out of the class designer
I’m not going to spend much more time on this blog post, describing the features of the class designer. This post is already quite long, and my main aim was to highlight its existence and explain why it is more useful than other modeling tools you may have used in the past, despite its smaller feature set. Also you should buy our upcoming book, which has got a whole chapter devoted to the class designer 
However I am going to finish off with a few tips and recommendations for getting the most out of the class designer.
- Install the PowerToys for the Class Designer. Actually don’t install it just yet, because there is a new version that supports VS 2008 coming out very soon. The PowerToys is a really useful add-in that provides a whole bunch of useful little extensions to the designer. This is really one of those instances where the sum is greater than the parts. It’s such a useful set of extensions that I’ll be devoting a post to it sometime in the future.
- Use the class designer to generate a class diagram any time you are given a new project – whether that be for the purposes of bug fixing, enhancement, refactoring, peer code review, or anything else. This is probably the single best use of the class designer that I’ve discovered – using it to bootstrap your understanding of the code’s structure. Even if you just create the class diagram temporarily and thrown it away afterwards. You always can create another diagram later if you want to actually do some refactoring or visual development.
- If you don’t have any associations shown as lines, then the layout tool won’t do too much. When I create a new diagram I do the following to quickly lay it out (Note this requires the PowerToys for the Class Designer):
- Ctrl-A to select all types on the diagram
- + on the number keypad to expand and show all members
- Select “Class Diagram-Filter Lines->Show All Associations” from the menu
- Select “Class Diagram->Layout Diagram”
- Select “Class Diagram->Zoom->Fit”
- For the bigger classes I typically collapse the Fields (the term used for private properties)
- Don’t forget that if you show associations as lines they will not be listed as members anymore on the class. This also applies to collection associations. This is quite different to the way many other modeling tools work and can be a rather annoying if you’re not used to it.
- The refactoring support in the class designer is pretty good, but for the most part you can do this in the code editor just as easily. However the cut, copy, and paste refactoring is great. This lets you move or copy methods or properties from one class to another. Very useful if you are modeling the public interfaces of a set of classes early on in a project and you want to get a feel for an alternative class design.
