> The first diagram shows that A associates with 0-many Bs. The diagrams
> are never really about classes, they're about instances of the classes.
> So the second diagram is simply a snapshot of one such association
> where anA associates with two Bs. No matter which you look at, both are
> examples of a 0-Many association, or at least it looks that way to me.
No, the first diagram shows that *class* A has an association with
class B, since there are no object instances shown. This diagram is
completely about classes, since there are no objects modeled. Thus, it
is not an example of a 0-to-many association, but rather a model that
states that any instance of A can have 0-to-many associations with
instances of B. There is a distinction. Associations exist between objects,
not classes. That is unless we're building a metamodel. :-)
In general, a class diagram is usually sufficient to model the semantics
of an application, i.e. no object diagrams are necessary. However, there are
some cases where modeling specific objects can convey important information.
Yes, the second (object) diagram is in fact a snapshot. It represents one
of many legal associations between instances of class A and class B. This
was my point. The cardinality of this association is 2, since there are
exactly 2 members of the set (of possible associations between A and B).
The multiplicity of the association between class A and B is zero to many.
As Constin points out, the actual ER term is cardinality constraint, not
cardinality. The cardinality of a set is the actual number of members at
any given time, not the maximum allowable number of members.
> I'm still missing something, eh?
> >Cardinality refers to the *actual* number of cardinal (basic) members
> >in a set (http://whatis.techtarget.com/definition/0,,sid9_gci498885,00.html).
> >Since a UML class diagram is modeling classes, and not objects, i.e.
> >instances of classes, there are no sets defined. Multiplicity defines the
> >minimum and maximum number of objects that can be linked together through
> >an association.
> >In a nutshell, a class diagram models metadata, and an object diagram
> >models a single instance of the corresponding class diagram.
> >For example, given the class diagram:
> > *
> > :A -------> :B
> >a corresponding object diagram might look like:
> > anA:A -------> aB:B
> > |
> > -------> anotherB:B
> >The class diagram has a multiplicity of many (*), but the cardinality
> >of the A-B association in the object diagram is 2.
> >Yes, I believe they had read the relevant ER literature, and discovered
> >that it was wrong. ;-)
> >>I was reading some UML text tonight and thought it curious that it used
> >>"multiplicty" to describe associations rather than the (I thought) well
> >>established term, "cardinality." Is there a reason for that? It seems
> >>like a word stretched to the limits to look like original thought. Had
> >>they not read the relevant ER literature or do they really mean
> >>something completely different?