If you think about it, our Customer class can be seen as a specialised version of a more general class: Person. A Person would have a firstName and lastName but would not have an accountNo or orders or payments in our system. The Customer can be thought of as inheriting the two name fields from Person and the behaviour represented by getName () but having additional more specialised fields and behaviour in a purchasing environment. In fact we can say a Customer object is a Person. Java can represent this too, as we will see shortly. Then, anywhere in our Java code that a Person object is required, a Customer object will satisfy because a Customer is a Person.
We also say that Customer is a subclass of Person or that it extends Person. Person is said to be the superclass of Customer.
On the other hand the relationship between Customer objects and Order objects is different. Customers have Orders, so the relationship is called a has a relationship.
UML class diagrams can show these (and other) kinds of relationships between classes by means of different kinds of arrows. But that would take us away from our main aim of learning Java. Suffice it to say that UML class diagrams can be very useful in designing classes and their interrelationships in a system.