The Unified Modeling Language has a diagram type for showing classes:
a class diagram. A class will have instances, but UML does not have a
straightforward diagram type for them. People often use the UML
collaboration diagram to show a collection on instances, which is also
called a “snapshot” because it shows just an instant in time of a
Separately, software architects have identified three primary
viewtypes: Module, Component & Connector, and Allocation. (See
Each viewtype is a category containing many views, such as the class
diagram and snapshots we just discussed. Viewtypes are by definition
hard to reconcile with each other, but it is easy to reconcile views
within a viewtype. Let’s rename the “Component & Connector” viewtype
to be the “Runtime” viewtype because we’re generalizing this viewtype
to include all runtime views.
I have worked with information models and snapshots, and separately
thought about module and runtime viewtypes, but today I recognized a
connection between them. Information models, such as UML class
diagrams, are a kind of module viewtype. You can inspect the source
code (also part of the module viewtype) and directly see the classes
and their attributes.
Instances, however, are not created until runtime, so are part of the
runtime viewtype. You cannot see instances when you look at the
source code unless you “run the code in your head” to envision what it
There’s an interesting wrinkle though. A UML class diagram often
includes more information than you can directly inspect from the
source code. For example, the program might respect the invariant
that a Vehicle has an even number of Wheels. You can’t tell this by
looking at the code superficially, you’d have to either run the code
or exhaustively analyze the code to validate the invariant. A class
diagram would show the Vehicle and Wheel classes with an association,
and the multiplicity would be EVEN, or have an equivalent annotation.
So a class diagram is only mostly in the module viewtype.
subscribe via RSS