Uml Class Diagram

Drawing UML class diagrams by dragging boxes is slow. Here you describe the model in plain text — classes with their attributes and methods, then one line per relationship — and the diagram is drawn with proper UML notation. Edit the text and it redraws instantly; download SVG for documents or PNG for slides.

Text syntax

The syntax is similar to popular text-based diagram tools, so a model written here is easy to move later.

UML relationship notation

Multiplicity

Multiplicities are written at the end of the line next to the class they describe: in Customer "1" -- "*" Order, each order has exactly one customer and each customer has zero or more orders.

Worked example: an online shop

The sample model describes a small ordering system. A Customer places many Orders; each Order is composed of one or more OrderLines, each pointing to exactly one Product. Payment is abstract with a concrete CardPayment subclass, which also implements the Refundable interface, and an Order aggregates its Payment. The layout puts parents and wholes above their parts, so inheritance arrows point upward and composition diamonds sit at the top of each relationship.

Good class diagram habits

• Model one topic per diagram; split large systems into packages.
• Show only the attributes and operations that matter for the diagram’s purpose.
• Name associations with verbs (“places”, “contains”) where the meaning isn’t obvious.
• Prefer composition only when the part truly can’t exist without the whole.
• Keep diagrams in version control as text — this format makes that easy.

Reading the sample diagram

Start at the top: Customer and the abstract Payment class sit on the first row because nothing above them owns or generalises them. Order appears below Customer with the label “places” and multiplicities 1 and *, read as “one customer places many orders”. The filled diamond on Order’s end of the line to OrderLine says an order is composed of its lines; the hollow diamond toward Payment says an order has a payment that could exist independently. CardPayment points up to Payment with a hollow triangle (inheritance) and to Refundable with a dashed line and hollow triangle (it implements that interface).

Visibility and types

Types follow a colon (name: String) and operation return types follow the closing bracket (total(): Money). For early design sketches you can leave types out entirely; the diagram still draws.

Stereotypes and abstract classes

Guillemets such as «interface», «abstract» and «enumeration» are stereotypes — labels that extend UML’s basic vocabulary. Abstract class names are also shown in italics, as the diagram does for Payment. Teams sometimes add their own stereotypes like «entity» or «service» to show architectural roles; keep them consistent across diagrams.

From diagram to code

Class diagrams describe structure rather than behaviour, so they map naturally onto classes, fields and method signatures in object-oriented languages. They are equally useful for designing database tables, where associations with multiplicities become foreign keys and link tables.

When to draw a class diagram

• Planning a new feature or module before writing code.
• Explaining an existing codebase to new team members.
• Designing a domain model with non-developers — keep it at the concept level, without types and visibility.
• Documenting an API’s data structures.
• Preparing for exams in software engineering courses.

Limits of the automatic layout

The layout places classes in rows by their relationships and draws straight connectors, which keeps small and medium models (up to about 15–20 classes) readable. Very large or densely connected models may have crossing lines; splitting them into several diagrams usually helps more than manual placement. For full UML tooling — sequence diagrams, code generation, round-tripping — use a dedicated modelling tool.

Privacy

Your model is drawn entirely in your browser and never uploaded, so it’s safe for internal designs.