The main reason I am making a crisp distinction is because people in the business-rules world make it. I could have happily used a class diagram forever to do this. Ron Ross says that the difference is in the perspective between fact models and logical data models. A presentation from one of his team members plus a couple conversations with him and a read of his book convinced me of the value of making the distinction.

Thanks, too, for the background on multiplicity versus cardinality. Sometimes I think I learn more from writing here than other people learn from reading here. Thanks for helping make that true.

Conceptual explication is precisely about distinguishing static concepts and understanding the relationships among them. A UML static structure diagram that shows concepts, associations, and multiplicities thus directly addresses explication.

By the way, it’s not so much that Visio chose the term “multiplicity”, but that the term is part of UML. A multiplicity applied to a concept or class specifies a range of possible cardinalities of instances of that concept or class.

While a class diagram can be used for explication – and that’s what I had always used until last year – I believe a fact model is more effective. After we wrap up this series on class diagrams, I’ll cover fact models. They are very similar, but a fact model does not include cardinality data, and usually does not include attributes. It also introduces the notion of contextual synonyms (e.g. A quote is an order after the customer agrees to purchase).