views:

4604

answers:

5

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?

A: 

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
Arne Burmeister
what does the arrow near Food mean? i've thought that this is used just to identify which class uses which one, but in Microsoft Visio to set an arrow on one of the sides you have to check "is navigable" so i thought it might mean something else.
agnieszka
and why don't we write an association line between Cat and Food? it uses the Food as well. or is it just "we don't, end of story"?
agnieszka
Because it would be redundant. The diagram already tells us an animal uses food, and a cat "is a" animal. Therefore a cat uses food. An extra arrow would be clutter.
slim
is it the same with methods? do i need to write that Cat has a Feed method or is it enough that IAnimal has one?
agnieszka
It is enough that IAnimal has one.
slim
Actually, implementing an interface should not be interpreted as a "is a" relationship. Interfaces are contracts and classes which use them are binding themselves to the contract. Inheritance is the only relationship which expresses an "is a".
etsuba
Some of your terminology is not UML: from IAnimal to Food should be a 'Dependency', and from Cat to IAnimal and Dog to IAnimal should be a 'Realization'.
chimp
A: 

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."

slim
I'd disagree on the arrowhead being optional - in this case the names give you an obvious clue, but that's not usually the case and clarity is everything in documentation
annakata
you are right, but it is your decision which detail you want to document. You can remove all methods from the class diagramm, you may draw different ones choosing only some associations for each. This is often usefull for large diagrams which will be cluttered with lines everywhere.
Arne Burmeister
Edited my answer to clarify this.
slim
A: 
Nikola Stjelja
well that's not true as far as i know. this is how class diagrams in visual studio work but they are NOT uml diagrams.
agnieszka
A: 

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.

duffymo
+6  A: 
toolkit