Python Class Diagram Examples: UML Patterns for OOP in Python

Python's object-oriented features — inheritance, abstract classes, protocols, dataclasses — all have UML class diagram equivalents. If you are documenting Python code or designing a Python system architecture, knowing how to map Python concepts to UML saves time.

This post covers the most common Python OOP patterns and their class diagram representations, with Mermaid syntax you can paste directly into the free Badger tool.

Python Class Inheritance in UML

Python inheritance maps directly to the UML inheritance arrow. A subclass that uses class Dog(Animal): is shown with the inheritance (<|--) relationship:

classDiagram
  class Animal {
    +str name
    +int age
    +speak() str
    +move() None
  }
  class Dog {
    +str breed
    +fetch() None
  }
  class Cat {
    +bool is_indoor
    +purr() None
  }
  Animal <|-- Dog
  Animal <|-- Cat

Python uses snake_case for attributes and methods — keep that in your diagram if your audience is Python developers, or use camelCase if you are targeting a mixed audience.

Abstract Base Classes in Python

Python uses the abc.ABC module for abstract classes. These map to the <<abstract>> stereotype in UML:

classDiagram
  class Shape {
    <<abstract>>
    +str color
    +calculate_area() float
    +calculate_perimeter() float
  }
  class Circle {
    +float radius
    +calculate_area() float
    +calculate_perimeter() float
  }
  class Rectangle {
    +float width
    +float height
    +calculate_area() float
    +calculate_perimeter() float
  }
  Shape <|-- Circle
  Shape <|-- Rectangle

Methods marked with @abstractmethod in Python are shown as declared (no body) in the parent class. Subclasses provide the implementation.

Sell Custom Apparel — We Handle Printing & Free Shipping

Dataclasses and Composition

Python dataclasses are just classes with auto-generated __init__. They work the same way in UML. Composition is shown with the filled diamond:

classDiagram
  class Address {
    +str street
    +str city
    +str zip_code
    +str country
  }
  class Customer {
    +int customer_id
    +str name
    +str email
    +Address address
    +get_full_name() str
  }
  class Order {
    +int order_id
    +float total
    +list items
    +add_item(item) None
    +calculate_total() float
  }
  Customer *-- Address
  Customer "1" --> "0..*" Order : places

Address is composed inside Customer — if you delete a Customer record, its Address goes too. The association from Customer to Order shows the relationship without implying ownership.

Python Protocols (Structural Subtyping)

Python 3.8+ introduced Protocol from the typing module — similar to Go interfaces or TypeScript structural typing. A class satisfies a Protocol without explicitly inheriting from it. In UML, use the <<interface>> stereotype and the realization arrow:

classDiagram
  class Drawable {
    <<interface>>
    +draw(canvas) None
  }
  class Resizable {
    <<interface>>
    +resize(factor float) None
  }
  class Widget {
    +str name
    +int x
    +int y
    +draw(canvas) None
    +resize(factor float) None
  }
  Drawable ..|> Widget
  Resizable ..|> Widget

Widget satisfies both protocols without inheriting from them. The realization arrow (..|>) captures this relationship.

Django Model Class Diagram Example

Django models are Python classes with database backing. A simple blog domain:

classDiagram
  class User {
    +int id
    +str username
    +str email
    +str password_hash
    +date joined_at
  }
  class Post {
    +int id
    +str title
    +str content
    +datetime created_at
    +bool is_published
    +publish() None
    +get_preview() str
  }
  class Comment {
    +int id
    +str body
    +datetime created_at
  }
  class Tag {
    +int id
    +str name
    +str slug
  }
  User "1" --> "0..*" Post : writes
  Post *-- Comment
  Post "0..*" --> "0..*" Tag : has

This covers Django's ForeignKey (Post has author User, Comment belongs to Post) and ManyToManyField (Post has Tags). Composition is used for Comments because they do not exist without their Post.

Frequently Asked Questions

Should I use snake_case or camelCase in Python class diagrams?

Use whatever matches your audience. If the diagram is for Python developers familiar with the code, snake_case is more natural. If you are presenting to a mixed audience, camelCase is the UML convention and may be more readable.

How do I show a Python Protocol in UML?

Use the <> stereotype with the realization arrow (..|>). Even though Python Protocols use structural typing rather than explicit inheritance, the UML representation is the same as an interface.

Can I draw Python dataclass diagrams the same way as regular classes?

Yes. Dataclasses generate __init__ automatically but they are still classes. Represent them as regular class boxes in UML — the auto-generation detail is an implementation concern, not a structural one.

How do I represent Django ForeignKey in a class diagram?

A ForeignKey creates a many-to-one relationship — use a directed association arrow from the many side to the one side, with cardinality labels: Post "0..*" --> "1" User.