Brand
Get all logo versions.
Download 
A class diagram is UML's structural blueprint: the classes in a system, their attributes and methods, and how they relate, from inheritance to composition. This template is the class diagram of a Python task runner: six classes with typed attributes, dataclass and enumeration stereotypes, visibility markers, and a self-association. Developers use it to design before coding and to document the code that exists.
Both draw boxes with attributes and connect them, which is where the resemblance ends. The class diagram is about objects in code: methods, visibility, inheritance, composition, dependencies, the living behavior of a system. The ER diagram is about data at rest: entities, keys, and cardinality, destined for tables. Design the software with a class diagram; design its database with an ER diagram. Most products need both, and the entities will overlap without matching one to one.
A class diagram is the UML diagram that shows a system's static structure: its classes, each with attributes and methods, and the relationships between them, inheritance, association, aggregation, composition, and dependency. It's the most used UML diagram, drawn at three levels of detail: conceptual for domain modeling, design for architecture, and implementation for diagrams that map one-to-one onto code, like this template's.
Each class is a box with three compartments: name, attributes, methods. A + prefix means public, - private, # protected. Lines carry the relationships: a solid line is an association (with multiplicities like 1 or 0..* at the ends), a hollow diamond is aggregation, a filled diamond is composition, a hollow triangle arrow is inheritance, and a dashed arrow is a dependency, often labelled «use» or «create».
This template's board is one: a task runner where a Runner «uses» a Workflow, the Workflow aggregates Tasks (0..*), each Task carries typed attributes like func: Callable and retry settings, holds a status from a TaskStatus «enumeration», and depends on other Tasks through a 0..* self-association. Tracing one feature through the diagram, say, how a failed task marks its dependents as skipped, is a good test that the structure holds.
A class diagram models objects with behavior: classes carry methods, visibility, and dependencies, and the relationships include inheritance and composition. An ER diagram models stored data only: entities, attributes, keys, and cardinality, with no methods anywhere. They often describe the same domain; the Task class here would flatten into a tasks table in the database's ER diagram, losing its methods on the way.
Three moments pay best. Before building: a design-level diagram settles where responsibilities live while moving them is free. Before refactoring: reverse-engineering the current structure exposes the tangles you're about to touch. And when onboarding: the diagram is the map a new engineer reads first. Skip the conceptual-everything diagram of the whole codebase; one diagram per subsystem, at the detail level the audience needs.