Uml Class Diagram Inheritance Examples for Beginners: a Simple Guide

If you're learning UML and trying to understand how objects relate to each other in software design, inheritance is one of the first relationships you'll encounter. It's also one of the easiest to model in a class diagram once you see a few clear examples. This matters because inheritance is the backbone of object-oriented programming and if you can't diagram it, you'll struggle to communicate your designs to teammates, instructors, or interviewers.

What is inheritance in a UML class diagram?

Inheritance in UML represents an "is-a" relationship between classes. A child class (also called a subclass or derived class) inherits attributes and methods from a parent class (also called a superclass or base class). In a UML class diagram, this relationship is drawn as a solid line with a hollow triangle arrow pointing from the child to the parent.

Each class is drawn as a rectangle with three compartments: the class name at the top, attributes in the middle, and methods at the bottom. When inheritance is involved, the child class automatically gains everything defined in the parent, but can also add its own attributes and methods or override inherited ones.

How do you draw an inheritance relationship?

Here's the step-by-step process:

Draw a rectangle for the parent class with its name, attributes, and methods.
Draw a separate rectangle for the child class with any additional or overridden members.
Draw a solid line from the child class to the parent class.
Add a hollow (unfilled) triangle on the end of the line that touches the parent class. The triangle points toward the parent.

The arrow direction trips up beginners constantly. Remember: the arrow always points to the parent. Think of it as the child "pointing up" to where it came from.

Can you show a simple inheritance example?

Let's say you're designing a system for a zoo. You have a base class called Animal and two child classes: Mammal and Bird.

Animal (parent class):

Attributes: name, age, weight
Methods: eat(), sleep()

Mammal (child class of Animal):

Additional attributes: furColor
Additional methods: nurse()

Bird (child class of Animal):

Additional attributes: wingspan
Additional methods: fly()

In the diagram, both Mammal and Bird would have their own lines with hollow triangles pointing up to Animal. This is called single inheritance each child has exactly one parent.

What does multi-level inheritance look like?

Inheritance can go deeper than one level. Continuing the zoo example, you might add a Dog class that inherits from Mammal, which in turn inherits from Animal.

In this chain:

Dog inherits everything from Mammal (furColor, nurse())
Mammal inherits everything from Animal (name, age, weight, eat(), sleep())
So Dog ultimately has all attributes and methods from both levels

You'd draw this as three rectangles stacked vertically, with the inheritance arrows chaining from Dog → Mammal → Animal. This kind of class hierarchy is extremely common in real codebases.

What's the difference between inheritance and interface realization in UML?

Beginners often confuse these two because they look similar in diagrams. Here's the distinction:

Inheritance (generalization) uses a solid line with a hollow triangle. The child class inherits actual implementation (code) from the parent.
Interface realization uses a dashed line with a hollow triangle. The implementing class promises to provide the methods defined in the interface, but doesn't inherit any code.

If you're working with Java or C#, this distinction directly maps to extends vs implements. Understanding both relationships is essential before you start thinking about generating code from your UML diagrams.

Why do beginners get inheritance diagrams wrong?

These are the most common mistakes I've seen:

Arrow direction reversed. The hollow triangle must point to the parent, not the child. This is the number one error.
Using the wrong line style. A dashed line means interface realization, not inheritance. Solid lines for generalization.
Duplicating inherited members. Don't list the parent's attributes and methods again inside the child class rectangle. The child inherits them automatically only show what's new or overridden.
Ignoring visibility markers. Use + for public, - for private, and # for protected. Protected members (#) are especially relevant in inheritance because they're designed to be accessible by child classes.
Overusing inheritance. Just because two classes share some attributes doesn't mean one should inherit from the other. If the relationship is "has-a" rather than "is-a," use composition instead. This is a design principle that becomes more important when you start working with advanced UML patterns for scalable systems.

How does inheritance connect to abstract classes and methods?

In UML, abstract classes and methods are written in italics. An abstract class can't be instantiated directly it exists to be inherited from. An abstract method has no implementation in the parent and must be overridden by the child.

For example, if Animal has an abstract method makeSound(), then Mammal and Bird must each provide their own version. In a class diagram, you'd write the class name and method name in italics to signal this. Some tools also show the class name followed by {abstract} as a constraint.

This matters in practice because abstract classes enforce a contract they tell other developers exactly what each subclass needs to implement.

What about multiple inheritance in UML?

Some languages like C++ and Python support multiple inheritance, where a single child class inherits from two or more parents. In UML, you simply draw multiple inheritance arrows from the child one to each parent.

If a class called SwimmingBird inherits from both Bird and Swimmer, you'd see two lines with hollow triangles pointing to each parent. Keep in mind that Java and C# don't allow this with classes (only with interfaces), so whether you model this depends on your target language. When designing for complex real-world applications, these language constraints heavily influence your diagram choices.

What's a real-world example of inheritance in a class diagram?

Think about a payment processing system:

PaymentMethod (abstract parent): attributes amount, currency, transactionDate; methods processPayment(), refund()
CreditCard (child): additional attributes cardNumber, expiryDate; overrides processPayment()
PayPal (child): additional attributes email; overrides processPayment()
BankTransfer (child): additional attributes accountNumber, routingNumber; overrides processPayment()

This is a textbook example of polymorphism in action. The parent class defines the interface, and each child provides its own implementation. In the diagram, all three children point up to PaymentMethod with solid lines and hollow triangles.

Quick tips for clean inheritance diagrams

Keep inheritance hierarchies shallow two or three levels deep at most. Deep hierarchies become hard to reason about.
Name parent classes as general concepts (Animal, Vehicle, PaymentMethod) and children as specific types.
Use the # (protected) visibility for attributes and methods in the parent that children will need to access.
Mark abstract classes and methods in italics so the diagram communicates intent clearly.
If two classes share behavior but aren't in an "is-a" relationship, consider composition (a filled diamond) instead of inheritance.

You can find more references on UML notation at the official UML specification page from the Object Management Group.

Beginner's checklist before you finalize your inheritance diagram

Every child class has a solid line with a hollow triangle pointing to its parent.
No child class duplicates attributes or methods already defined in its parent.
Abstract classes and methods are shown in italics.
Visibility markers (+, -, #) are correct and consistent.
The hierarchy makes logical sense every relationship is truly "is-a," not "has-a."
The diagram works for your target programming language (check multiple inheritance rules).
You've reviewed for deep nesting flatten the hierarchy if it goes beyond three levels.

Start by sketching one parent and two child classes on paper. Use the checklist above. Once that feels natural, practice with abstract classes and multi-level chains. Diagramming inheritance is a skill that gets easier fast once you've drawn five or six examples by hand.