Raising the Level of Abstraction

Of course, the UML itself is an example of "technical jargon." It is now the way software professionals talk to each other about software. As each example of a notation becomes deeper and denser, it can become an esoteric and subtle way of expressing ideas and designs that are very rich and complex. Yet, at the outset, this (and any) notation, at its highest level of abstraction, is useful for communicating between professionals and "civilians." That is because its fundamental elements can still be used to transmit fundamental ideas. A truly great notation "nests" and has many levels of abstraction; the highest levels facilitate communication between people who are "farthest apart" in terms of background and context, whereas the lowest levels (with the most technical detail) aid communication between people who are "closest together" in terms of their understanding of the domainthe technical specialists.

What has been interesting about our journey is that I have used analogy to explain a technical notation. I have avoided the "self reference" trapin other words, I have explained the UML without describing the UML itself. I have explained the jargon without using the jargon. Although this seems like a subterfuge at first ("Hey, wait a minute; I never even got to see a UML diagram!"), it is, in fact, a requirement that you be able to explain it without using it.

Otherwise, those "civilians" are going to balk the first time you draw one. With this introductory context, however, I believe that the first UML diagram you do draw will be much better received. They will hark back to "1+1," Pythagoras, and Ohm's Law, and know that you are doing the same thing for software constructs.