2

I'm trying to make a UML class diagram for a very simple scenario. Consider the following code: List<Food> foods = {new Tomato(), new Pizza()}; as a field to class A. Clearly, class A has associations between Tomato and Pizza, but should it also have an association between Food?

Of course, Tomato and Pizza extend from Food :)

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
user13276800
  • 23
  • 4
  • do not use association nor dependencies as proposed in the answers in the class diagram, else you will have a *boodle dish*. If you want to highlight that better use an object diagram – bruno May 08 '20 at 12:04

3 Answers3

2

The use of generics such as List<Food> is always a challenge in UML, since the semantics of generics are not the same across the programming languages.

Here, the field foods of class A means that there is a navigable association from A to Food. And Tomato and Pizza are specializations of Food (based on your use of the term "extend"):

UML class diagram

Additional remarks:

  • The association is with Food, because the type is List<Food> and there is no direct coupling between A and Tomato or Pizza.

  • Keep in mind that a class diagram shows the general picture and not a specific scenario with individual objects (that was the purpose of the former object diagram).

  • The use of a list tells that the association can be with be 0 or more Food. But we don't know if one Food object could be used by several A or not (several is theoretically possible if Food would be a reference type): therefore the multiplicity is unspecified on the A side.

  • Based on the semantics, you may consider making the association a composition or an aggregation. But a simple association is correct in any case.

  • Based on the what you want to highlight about your design in the A-to-Food association:

    • you may prefer the dot notation on the Food end, if you want to underline that the association (aka the list) is owned by A
    • you may just use navigability notation as in my diagram, if care less for the current implementation and just want to express that accessing Food from an A should be easy.
    • you may show none of the above, if you want to keep these topics open.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • The property `foods` of class `A` does not represent a *navigable* association end, but rather an association end that is "owned" by `A`, visualized with an ownership dot in the class diagram. Of course, such an owned association end implies navigability. If you would correct this in your answer, it would deserve a +1. – Gerd Wagner May 09 '20 at 13:48
  • @GerdWagner That dot notation should be the new standard. But tools (like EA) make it hard or impossible to create. – qwerty_so May 10 '20 at 08:53
  • @GerdWagner Thank you for your interesting remark. I’d really have to take a more profound look at the dot notation. But my claim here, is that ownership cannot be decided for sure with the info we have. If Food is a reference type, its subsequent lifecycle is independent of A. Furthermore, the initialization is just a scenario: nothing tells us that an existing Food may not be added later to the list, nor that Food has no constructor or setter that would allow to establish the association and enable the reverse navigation(this is why I left the reverse navigation undecided and not disabled). – Christophe May 10 '20 at 09:56
  • @Christophe : The UML jargon of "association end ownership" is not related to the (confusing) debate of composition/components being "owned" in the sense of a lifecycle dependency, to which you are referring. Please see https://stackoverflow.com/questions/47773220/what-does-the-dot-mean-at-the-end-of-an-association/47774920#47774920 – Gerd Wagner May 10 '20 at 13:30
  • @GerdWagner I get your point: The list is owned by A so you recommend to show the ownership in the diagram. That's a indeed valid choice that would be closer to current implementation. My choice to set the focus on navigability regardless of how the association is owned/implemented is nevertheless valid as well (UML quote says:"*ownership MAY be indicated graphically*", and not "*MUST*"). UML specs tells us also that "*Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation*". I've edited to give OP the full picture.Thanks for your advice – Christophe May 10 '20 at 14:39
1

Without seeing more details it's difficult.

Your food is a 0..n multiplicity association.

Both Tomato and Pizza do not have an explicit assocation in that code. So that's just a dependency.

An association is a stronger form of a dependency (sloppy definition that is). Actually you can create an association. It depends on the yet unknown details. If your focus is on the list and you want any subclassed food in it, you would not draw associations to each of these subclasses but only to the parent class Food.

As said: it all depends and as a design template the details from the template need to be more beefy.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Huh. I thought there was an association with another class whenever it is stored as an attribute. Since ```List foods = {new Tomato(), new Pizza()};``` as an attribute is equivalent to ```foods.add(new Tomato()); foods.add(new Pizza())``` in the constructor, why is it dependency? Am I misunderstanding something? – user13276800 May 08 '20 at 12:03
  • 1
    You don't have a named association for tomato and pizza. They only live inside a list. If you had a `Tomato myTomato = new Tomato()` (or whatever the syntax would be) you had an assocation with a role name. An association is a stronger form of dependency. – qwerty_so May 08 '20 at 14:02
1

I would say your ClassA has a structural relation (association) to Food.

Because it also calls the constructors of Tomato and Pizza it has a dependency to those classes.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
  • these dependencies are useless unless the goal is to make a *noodle dish* (to stay in the culinary field) – bruno May 08 '20 at 12:01
  • @bruno care to explain why those dependencies would be useless? I don't get the reference to *noodle dish* – Geert Bellekens May 08 '20 at 12:17
  • when there are a lot of relations in a model/diagram that makes a *noodle dish* (each relation is like a boodle and the diagram a dish), you never use that expression in Belgium ? May be you prefer *plate of fries* ? ;-) – bruno May 08 '20 at 12:26
  • 1
    No we don't use "noodle dish" in Belgium :). I wasn't necessarily talking about putting all those relations on a diagram. But the dependencies are there, whether you show them on a diagram or not. If one was to delete the class `Tomato` it would have a direct effect on ClassA. This is not the case with the class `FrenchFries` although that would supposedly also be a `Food`. – Geert Bellekens May 08 '20 at 13:55