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 Models.
This is our slightly enhanced reference concept model:
Puppies3

Omissions in ”Boxes and Arrows” types of diagrams

Here follows an (almost) equivalent representation expressed as a generic UML-style class diagram (keys hidden):
ClassDiagram2
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 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.

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 attribnute - 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 Modelling the mantra is: Less is More! Intution is obstructucted by unnecessary information. UML class diagrams offer (at least) metaconstructs 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).