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.