In this article I want to summarize our experiences in teaching UML. We have been offering UML for over a year now as part of our OOAD course; before that we had taught OMT and Fusion similarly. We have gained some valuable lessons on what people like, what they enjoy, where they have the most problems, and how to address these problems.

Our approach to all our courses is similar in one sense. We are acutely conscious that students are taking time away from their work or leisure to come to our classes. We feel responsible for making it worthwhile for the them. To this end we strive to make our offerings concise, with a hard focus on the practical. We have been gratified - our students tell us they find our courses solid, compact, and packed with practical information and hands-on experience.

Who attends?
The OOAD class gets a range of attendees - some have programmed in OO languages, others are programmers but new to OO. Some are familiar with pre-UML techniques and want to learn UML. We also get managers who don't program, but want to know about OO analysis and design. Our task is to take students from varied backgrounds and get them thinking and formulating in objects. We are constantly aware that this cannot be done by putting them in a straightjacket - creativity cannot be made-to-order, but can we at least give them the tools to formulate problems clearly, understand why one formulation can be considered better than another? Can we get them to abstract? Can we get them to communicate their analysis? This is where UML can play a significant role.

Putting UML in perspective
UML is only a diagramming technique - a comprehensive one, perhaps, and certainly an extensible one - but still only a standard mechanism to draw pictures. It may be indispensable, but it is certainly not sufficient. An OOAD course must present a balanced view of where UML fits into the methodology, and how it can help clarify analysis and tradeoff rival models. This is a constant theme in our course.

Do code examples help?
The course is not based on any specific OO language. We state this at the outset, and also in the course outline. This is because too many courses on OOAD deteriorate into language debates - not even arguments over OO features supported by this language or that - but over language syntax and such. On occasion, students do ask how a particular UML construct - say composition or aggregation - would be achieved in a language. This must and is answered by putting up a short code fragment in the language.

Where do students stumble?
We have found that the most students falter, not in their ability to comprehend individual concepts, such as what inheritance means or what associations can represent, but in the far more basic (and essential) exercise of ignoring information. The art of simplification at the center of object orientation, and it is surprisingly hard to teach. Nature or nurture has taught people that complexity is good, and worse, that sophistication in design is revealed in its complexity - so much so that they are somewhat sheepish if they have found a simple way to represent something. Of all the battles fought in the OOAD class I think this is the most vital. Our labs illustrate how even complex problem statements can be pared down to their essentials and stated simply. Students are first surprised, then delighted.

Does a real tool help?
Yes and no. Although we do point students to several of the UML tools in the market - even some available free for evaluation, we have opted against using an automated tool in our class itself. This is because we want students to focus on UML, not on the tool. Some of our students are able to use the tool, but not as confident about their design decisions. Others are unfamiliar with both. As they stand, the tools take some learning, and this would be time taken away from learning the UML as far as this class is concerned. Our students have had no difficulty taking what they have learned in the classroom and using their tool of choice in the workplace. When we find a tool that is simple enough to use that it does not distract from the main goal, we will likely use it.

CRC or no CRC?
CRC is, strictly speaking, not part of UML. On the other hand, it is a time-tested technique for teaching OO. We use it. We also teach when to drop it. It is, as they say, like a boat - an artifice to be left behind after the crossing.

Example City
Examples are the lifeblood of any instruction. A good example is worth a thousand words (and pictures, and books). To succeed, examples must be short, succinct and focused. The student must know what is being illustrated, and the illustration must be immediately obvious. It is also necessary that the examples must be from domains everyone is familiar with. We choose simple domains - telephones, televisions, grocery stores, etc. for our domains. Students love it. We invariably get specific mention of our examples-based instruction in the course evaluations. Here are a couple of examples: