The most familiar UML diagram is the class diagram.  A class diagram can mean many different things.  If you look around a room in which developers are writing software, you’ll often see whiteboards with UML class diagrams on.  This is UmlAsSketch.  The rectangles on these diagrams are 1:1 with the code.  But this raises something of a conflict with the UML specification.  Let’s say the code is C# - which it often is, where I work.   C# only has single inheritance of classes, while UML has multiple.  C# has fields, properties, methods, events, indexers, constructors and destructors, while UML has attributes and operations – actually C# has attributes too, but they mean something completely different.  UML defines visibility to be public, private, protected and package: C# agrees on the first three, but also has internal and protected internal and does not have package.

A second popular use for UML class diagrams is conceptual object models (often called analysis models).  The classes in these models don’t represent actual classes in the code; instead they represent conceptual entities that interact to represent the behaviour of the proposed software without thinking much about implementation issues like persistence, user interaction, performance, or security.  Many authors wrote about using such diagrams for “object oriented analysis” during the 1990s: indeed that was the impetus behind the “unification” of the UML.  Proponents of Model Driven Development frequently generate code from these diagrams, and it’s this use of class diagrams that is best catered for by the current UML specification.

Another popular use for these diagrams is conceptual data models.  For example, a software designer who uses use cases to represent the interactions between system components needs to say what kinds of data traverse the lines in their diagram.  UML diagrams can be used to represent entities and relationships for this – although again, there are problematical mismatches between the specification and the way that the diagrams are used in practice.

Pragmatically, the UML class diagram is a successful reusable syntax, covering the uses I’ve listed above and more. But the current scheme of UML profiles falls short of representing these uses.  For example you can't change the visibility scheme, and it's very hard to find an effective way of representing C# properties that is consistent with the UML semantics.  So in Visual Studio we keep the physical and conceptual representations separate: the Class Designer looks rather like UML but directly represents the code, and we will also have the Logical Class Designer, which implements the UML specification and is used for logical (conceptual, analysis) class design.

What do you use Class Diagrams for?