CODEWITHSUNDEEP
inheritanceumlcompositionclass-diagram
Pirogov
Pirogov

Reputation: 37

UML Classes representation

I'm learning UML and want to create a small restaurant application, that has a menu, dishes contained in menu, products used in dishes. Menu is divided into different types that can contain only of the appropriate type. I suppose that class menu and dishes should be abstract. That's my UML diagram.

enter image description here

How to best display the relationship of abstract classes?

Upvotes: 1

Views: 1410

Answers (2)

bruno
bruno

Reputation: 32586

I put an answer after @Christophe did because in (the first version of) his proposal there are exceptionally some problems.

An order contains at least one dish. But an order is not composed of dishes, so there is no composition, and for me nor even an aggregation.

A dish is made from at least one product, using a given quantity of them. Depending on the product the quantity is a volume (for instance for a liquid), or a weight (for instance for butter) or a number (for instance for egg), etc. For that you can use a class-relation. The relation cannot be a composition because a given product can be used for several dishes.

A menu contains a least one dish, but a given dish can be used in several menus so a composition cannot be used. In my diagrams I use an aggregation but perhaps this is not a good idea.

Supposing you always need to have specialized classes for Menu and Dish you can have :

enter image description here

but I am not sure you always need these specializations, so Dish and Menu are not abstract even they can have specializations, and you can have :

enter image description here

(I suppose a dish is always part of at least one menu, this is a choice, so a 'preparation' made by cook but not part of a menu is not a dish)

As @Christophe said in a remark the customer can ask for some specific instructions (medium versus bloody for the meat etc), that can be supported by a class-relation :

enter image description here

Upvotes: 2

Christophe
Christophe

Reputation: 73366

First attempt

If we look at the requirements, i.e. that Orders are about Dishes, that Dishes are composed of Products, and that Menus are like catalogues of Dishes of some kind, we would come to such a diagram:

enter image description here

We'd show only a "relation" between the abstract Dish and the abstract Menu. The specialised dishes and menus inherit this association. It's just that you have to express with a comment on the association the constraint of using dishes compatible with the menu.

Further reflexions

The question is if we really need Menu specializations. This would be justified if they'd have very different behaviors.

Moreover, in your example you assume strict separation of the menu specialization. But what if at a later stage you'd have overlapping menus, e.g. Main menu with vegetarian, vegan and meat dishes, and a Vegan menu with only vegan dishes but for all kind of dishes.

If the behavior is the same for all the menu specializations and if this is only meant as an arbitrary categorisation (and if moreover, you'd have only one instance per class in practice), then it would be better to make Menu concrete and associate it with a Category class. By the way, you could also associate the abstract Dish to one or several Category, which would allow easier expression of the constraints you wanted.

Finally, it would be worth to explore the concept of association class and rethink what's between Order and Dish as well as between Dish and Product.

Upvotes: 2

Related Questions