One problem with using a uml diagram is that there is no way to indicate inheritance.

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 :

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 :

(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 :

Introduction

UML (Unified Modeling Language) is a graphical language for modeling the structure and behavior of object-oriented systems. UML is widely used in industry to design, develop and document complex software. This page will focus on creating UML class diagrams, which describe the internal structure of classes and relationships between classes.

For additional information beyond the usual suspects (your textbook and Wikipedia), see UML Basics: The Class Diagram.

Classes

A class diagram contains a rectangle for each class. It is divided into three parts.

1. The name of the class.
2. The names and types of the fields.
3. The names, return types, and parameters of the methods.

For example, a Person class and a Book class might be modeled like this.

This indicates that a Person object has private fields named name and birthDate, and that it has public methods named getName, setName and isBirthday. A Book object has private fields named title and authors. A Book object also has public methods named getTitle, getAuthors and addAuthor.

The examples below also model a Person class and Book class, but only shows fields or methods as needed for illustration.

Use Relationships

Often, objects and/or methods of one class use objects/methods from another class. For example, a person might read and/or own a book, and these relationships might be modeled in the UML diagram, so that they will be implemented in the corresponding program.

UML class diagrams include the following types of use-relationships, in order from weakest to strongest.

• Dependency: An object of one class might use an object of another class in the code of a method. If the object is not stored in any field, then this is modeled as a dependency relationship. For example, the Person class might have a hasRead method with a Book parameter that returns true if the person has read the book (perhaps by checking some database).

  

• Unidirectional Association: An object might store another object in a field. For example, people own books, which might be modeled by an owns field in Person objects. However, a book might be owned by a very large number of people, so the reverse direction might not be modeled. The *'s in the figure indicate that a book might be owned any number of people, and that a person can own any number of books.

  

• Bidirectional Association: Two objects might store each other in fields. For example, in addition to a Person object listing all the books that the person owns, a Book object might list all the people that own it.

  

• Aggregation: One object A has or owns another object B, and/or B is part of A. For example, suppose there are different Book objects for different physical copies. Then the Person object has/owns the Book object, and, while the book is not really part of the person, the book is part of the person's property. In this case, each book will (usually) have one owner. Of course, a person might own any number of books.

  

• Composition: In addition to an aggregration relationship, the lifetimes of the objects might be identical, or nearly so. For example, in an idealized world of electronic books with DRM (Digital Rights Management), a person can own an ebook, but cannot sell it. After the person dies, no one else can access the ebook. [This is idealized, but might be considered less than ideal.]

  

Inheritance Relationships

The inheritance relationships in UML match up very closely with inheritance in Java.

When a class inherits another class it is required to use all the data?

What does a subclass inherit from a superclass?

Which method would you use to determine whether a certain substring is the suffix of a string?

What gives a program the ability to call the correct method depending on the type of object that is used to call it?