UML class diagram association - how, when and why?

Question

I usually get so confused with UML and this situation is no different. Let's say I have an interface IAnimal, class Food and Cat:

interface IAnimal {
    void Feed(Food food);
}

class Cat : IAnimal {
    void Feed(Food food) {
        //code
    }
}

I've got 3 questions about drawing UML class diagram for these 3 elements:

• I assume I should use association between IAnimal and Food or Cat and Food. Should there be an arrow on one side of the association line, if yes, then on which side and why there?

• if I write Feed as an IAnimal method on diagram, should I write a method Feed inside class Cat or do I write only additional Cat methods?

• the most important: should the association be between IAnimal and Food, Cat and Food, or both?

Answer 1

UML defines a number of relationship types.

Relationships have a number of different notations:

• Association relationships have a base notation of a solid path
• Dependency relationships have a base notation of a dashed arrow
• Generalization relationships have a base notation of a solid path with a triangular arrowhead
• Realization relationships have a base notation of a dashed arrow with a triangular arrowhead (a mix of dependency and generalization)

Pictorially

+---------------------------+
|       <<interface>>       |
|           IAnimal         |
+---------------------------+                        +--------+
| + Feed(food: Food) : void |- - - - <<use>> - - - ->|  Food  |
+---------------------------+                        +--------+
              ^
             /_\
              |

              |

              |
        +-----------+
        |    Cat    |
        +-----------+

That is:

• The relationship between IAnimal and Food is a usage relationship. This is shown as a dependency with the stereotype «use»
• The relationship between IAnimal and Cat is a realization relationship.

Association relationships are used to indicate connections between two or more classifiers. This implies that at least one of the classes has an attribute of the other type (or a collection). In fact, attributes and association ends contain the same information and can be interchanged.

So, IMHO, the relationships you describe should not be modelled as associations.

Answer 2

How picky you are about this kind of stuff depends to a great extent on what you're using UML for in the first place.

If you have some sort of whizzy UML-to-code translator, then you need to be picky (but it looks like you're more comfortable with code than with boxes and lines - so why would you use such a tool?)

If you're simply using UML to communicate with other people, then you can afford to be somewhat less picky.

Craig Larman's "Applying UML and Patterns" stresses this point, by including diagrams that look as if they've been sketched on a whiteboard. A solid line which the UML standard says should be dotted is fine in that sort of diagram. So with arrowheads and so forth.

It's clear to me that the line should go from IAnimal to Food.

Whether the arrowhead adds clarity (for human readers) is a matter of choice, but it indicates a unidirectional relationship:

From this introductory piece:

"In a uni-directional association, two classes are related, but only one class knows that the relationship exists."

Answer 3

Assuming a class diagramm, you should have a "use" association between IAnimal and Food and a "is a" association between Cat and IAnimal and Dog and IAnimal:

    IAnimal ----> Food
     ^   ^
    //   \\
   //     \\
 Cat      Dog

Answer 4

I'd argue that IAnimal would have HAVE-A Food, since it's metabolized, but if you really want to denote HAS-A I think it should be an aggregation (open diamond) or composition symbol (filled in diamond), depending on the cascading delete characteristics.

There are two schools of thought with UML, according to Martin Fowler. There are the "sketchers", who use the notation on whiteboards and odd pieces of paper to communicate enough of their ideas to fellow developers.

Then there are those who view UML as engineering drawings, where every last detail of a design must be captured.

I'm firmly in the former camp. As a former engineer, I can tell you from personal experience that UML does not have the power of real engineering drawings to fully capture a software design.

If you happen to believe in the latter, please do a complete desktop or web UI design using UML and post it here.

Answer 5

1) No associations should be written between the interface IAnimal and the type Food. Associations are only used to connect types with proprieties inside classes. E.G

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

then you should write an association indicating the connection between those two types.

What you should draw instead is an dependency indicating that the interface IAnimal depends on the type Food. The dependency is drawn same as the association in the picture above, just change the straight line to a dotted one.

2) No, do not write those methods and do not write dependecies. Leave all notations only on the Interface IAnimal