An InstanceDiagram is a part of the UnifiedModelingLanguage that one does not see mentioned too often.  The basic idea is to make a static snap shot of instances (not classes) in your system or subsystem. Make it show exactly who points to whom.

----
VcapsProject uses an extended UML for our InstanceDiagram.  We use our extensions to show context related variability.  We try to show all the possible and allowed connections and combinations.  We are able to show the entire static structure of our GemStone database on OnePieceOfPaper.  Here is the legend:

http://members.aol.com/jdwells123/idlegend.gif

Here is a small example that I made up.

http://members.aol.com/jdwells123/example.gif

--DonWells
----
At a previous employer we were trying to encourage our "Business Analysis" team to think in terms of pre and post conditions. One way we tried to do this is to get them to draw instance diagrams for the state of a part of the system before and after an action. However, we had to sneak up on the idea. Instance diagrams were presented as collaboration diagrams without the messages.

--KeithBraithwaite
----
I've wondered for a long time why people make such a big deal of
class diagrams and tend to ignore instance diagrams.  I find that
I can never understand a system until I see instance diagrams.
As long as the authors of a system are around, it isn't hard to get them.
The authors know what the instance relationships are, but they prefer to
document the more abstract class relationships.  The class diagrams
are important, of course, since that is more like the code, but the
instance diagrams describe the run-time structure of your system.

Instance diagrams are especially useful if you use patterns like
Composite and Decorator, because then the class diagrams end up
looking a lot different from the instance diagrams.

So, my rule is to always make instance diagrams as well as class diagrams.
When I do, I find that I don't need a graphical representation for use cases.

-RalphJohnson
----
''I've wondered for a long time why people make such a big deal of
class diagrams and tend to ignore instance diagrams.''  Perhaps they are ScratchingTheItchOfHabit 
-----

I'm with Ralph in that I too need to visualize instances to understand what's going on.  In fact, I have always imagined a system more in terms of data and space than in terms of code.  In a way, the existence of code seems to me to be almost accidental versus being essential.

And I've always quietly wondered whether many other programmers share my preoccupation with data and space.  I wonder if iNtuiters (in the Briggs Meyers sense) tend to think more about data and space, while Sensers tend to think more about code.

----

In a UML class diagram, the cardinality indications on associations...those 1..* type things I instinctively apply.  They're an instance level construct, right?  Hmm...I'm not sure I like that aroma now that I've bothered to smell it.
-----
CategoryUml