The Puppy sample
The little Puppy / Kennel database originates from a poster issued by Database Programming & Design in 1989 about normalisation. In the version on this page, I have made a few amendments. The author of the example is Marc Rettig - the then technical editor of the magazine. The poster is a very good presentation of normalisation taken to the fifth normal form. Google for Rettig Normalization poster, and you will find it.

No UML, Please!

Here we will inspect some of the reasons that boxes and arrows as well as the rigid, but powerful, representations of eg. UML or even ER-diagrams, are not suited for Business Concept Maps.
This is our slightly enhanced reference concept model:

Omissions in ”Boxes and Arrows” types of diagrams

Here follows an (almost) equivalent representation expressed as a generic UML-style class diagram (keys hidden):

As you can see, there are a number of instances of information loss, some of which are:
  1. "Puppy Trick may be assigned Skill Level" becomes "Puppy Trick has Skill Level"
  2. "Kennel is situated at Kennel Location" becomes "Kennel has Kennel Location"
  3. Puppy Number and Puppy Name: the dependancies from Kennel are unclear
Number 1 would need NULL-specification in a database! But even that would not make it correct, because the original business terminology is lost. And lost means lost - it is not there - users have to guess at what the implied functional dependancy means. This is the most common problem - specific vocabulary degenerating to "has".
Number 2 has the problem that Kennel Location furthermore probably is a subtype of a generic Location concept, which is not in the model (yet?). In the diagram above it looks more like a design decision not to model Location in detail, but just to provide a long textfield for users to enter the location into. But that is really a solution level design decision. What we want to model is the reality of the concepts of the Business.
Number 3 is also confusing to users, and it could well be important for the business.

Concept Maps are best for Business People

Why Concept Mapping is the best for information driven business analysis is explained on the "BI RETIna" site. You might also want to have a look at my eLearning courses.
I have also written a book about how to use concept mapping for business analysis (instead of conceptual modeling with UML or E/R):


Design Thinking Business Analysis - Business Concept Mapping Applied
Thomas Frisendal
© Springer, 2012
ISBN 978-3-642-32843-5

What is wrong with UML?

Some of the of the problems are visualised above - here is a more comprehensive (and technical) list:
  • Loss on inter-attribute relationship information
  • Object or attribute - instead of just concepts
  • Multivalued attributes difficult to express in simple manner
  • Roles represented as attributes - how to depict uniqueness, exclusion/inclusion etc.
  • Object vs. association - often leads to new concepts and business key (previously unknown to the business).
The biggest problem, however, is complexity. For the purpose of Business Concept Modeling the mantra is: Less is More! Intuition is obstructed by unnecessary information. UML class diagrams offer (at least) meta-constructs such as:
  • Association vs. Aggregation vs. Composition
  • Generalisation, subtyping and Realisation
  • Inheritance
  • Multiplicity (cardinalities)
  • Data types etc.
All of the above is not really necessary for business users to understand. Obviously one answer could be to suppress / avoid using all of it in some simplistic class diagrams (if the diagramming tools permits that). But then, why use UML in the first place? Powerpoint or Visio boxes and arrows could be sufficient. But, as explained above boxes and arrows are not ideal for Business Concept Models. So no UML, please!
But further down the production line (in the design and specification phases there may well be good reasons to use UML, depending on the circumstances).