Class box anatomy
Every class in a UML class diagram is drawn as a three-compartment rectangle. The visibility symbol on each member encodes its access level:
| Symbol | Visibility | Meaning |
|---|---|---|
ClassName | Name compartment (top) | Class name, bold. Abstract classes are italicised; stereotypes (e.g. «interface», «enum») appear above the name. |
+ attribute: Type | Attribute compartment (middle) | Each attribute listed on its own line: visibility symbol, name, colon, type. Static attributes are underlined. |
+ method(): ReturnType | Method compartment (bottom) | Each method listed with visibility symbol, name, parameter list, colon, return type. Abstract methods are italicised. |
+ | public | Accessible from any other class. |
- | private | Accessible only within the class itself. |
# | protected | Accessible from the class and any of its subclasses. |
~ | package | Accessible from any class in the same package or namespace. |
Relationship types
Choosing the correct relationship type matters — inheritance and composition convey different lifecycle and coupling semantics that readers infer from the arrowhead style.
| Relationship | Notation | Meaning | Example |
|---|---|---|---|
| Association | Solid line (→) | One class holds a reference to another. Neither owns the other. | Customer → Address |
| Aggregation | Hollow diamond (◇→) | Whole/part; parts can exist independently of the whole. | Department ◇→ Employee |
| Composition | Filled diamond (◆→) | Strong whole/part; parts are destroyed when the whole is destroyed. | Order ◆→ OrderItem |
| Inheritance / Generalization | Hollow arrowhead (▷) | "Is-a" relationship. Subclass extends superclass. | SavingsAccount ▷ Account |
| Dependency | Dashed arrow (⟶) | One class uses another temporarily but does not own it. | ReportService ⟶ PdfExporter |
| Realization | Dashed hollow arrow (▷--) | A class implements an interface contract. | PayPalGateway ▷-- Billable |
When to use class diagrams
Class diagrams are useful at every stage of software development, but the appropriate level of detail varies by audience and goal:
| Use case | What to include | Typical audience |
|---|---|---|
| Domain modelling | Business entities, key attributes, relationships, multiplicities. Omit method signatures. | Product managers, domain experts, architects. |
| API design | Request/response types, service classes, interfaces, method signatures with return types. | Backend developers, API consumers, QA. |
| Database design | Entities mapped to tables, attributes as columns, associations as foreign keys, multiplicities as cardinality. | Database administrators, backend developers. |
| Codebase documentation | Full class details: visibility, static members, inheritance chains, dependency graph of a module or service. | New team members, code reviewers, maintainers. |
flow-chart.io adapts the diagram to your stated goal. Tell the AI what audience you are designing for and it adjusts the level of detail accordingly.
Example prompt and output
Type the following into flow-chart.io to generate an e-commerce order domain model:
E-commerce order domain: Customer (id, email, name) places many Orders. Each Order (id, status, placedAt) is composed of one or more OrderItems (quantity, unitPrice). Each OrderItem references a Product (id, name, price, stockQuantity). Order implements the Billable interface with a calculateTotal() method. Customer has a ShippingAddress (street, city, postcode). Show UML class diagram with visibility notation and multiplicities.
The generated diagram includes: five classes with typed attributes and visibility symbols; composition between Order and OrderItem (1 to 1..*); association with multiplicities between Customer and Order (1 to *) and between OrderItem and Product (* to 1); a realization arrow from Order to the Billable interface; and an association from Customer to ShippingAddress.
How AI class diagram generation works in flow-chart.io
- Entity extraction. The prompt is parsed to identify nouns as candidate classes, adjectives and phrases as attributes, verbs as method names or relationship labels, and cardinality words ("many", "one or more", "zero or one") as multiplicities.
- Relationship inference. Ownership language ("composed of", "contains", "has") maps to composition or aggregation. Reference language ("references", "belongs to") maps to association. Subtype language ("is a", "extends") maps to inheritance. Contract language ("implements") maps to realization.
- Typed scene graph generation. Each class becomes a three-compartment box with the UML-standard visibility symbols. Each relationship becomes a typed connector with the correct arrowhead. No freeform shapes — every element conforms to UML 2.5.1 notation.
- Layout pass. Inheritance hierarchies run top-to-bottom. The layout engine minimises line crossings and keeps related classes spatially close. The result is readable without manual repositioning.
Because the output is a structured scene graph, every element remains fully editable. Add an attribute, change a relationship type, rename a class, or adjust a multiplicity — without regenerating from scratch.
Class diagram best practices
- Keep each diagram to 8–12 classes. Split large models into packages and show inter-package dependencies on a separate diagram.
- Show visibility symbols (+, -, #, ~) on all attributes and methods — leaving them unmarked implies public and is ambiguous.
- Add multiplicities (1, 0..1, 1..*, *) to both ends of every association. "Customer to Order" without multiplicities is incomplete.
- Name associations with a verb phrase from the source-class perspective: "Customer places Order", not an unlabelled line.
- Use composition (filled diamond) only when the child's lifecycle is fully controlled by the parent; use aggregation or association otherwise.
- Mark interfaces with the «interface» stereotype and abstract classes with italicised class names, not freeform labels.
- Separate the interface from the implementation: define «interface» types and draw realization arrows from concrete classes that implement them.
Frequently asked questions
- What is a class diagram?
- A class diagram is a UML structural diagram that shows the classes in a system, their attributes, their methods, and the static relationships between them — inheritance, association, aggregation, composition, dependency, and realization. Each class is drawn as a three-compartment rectangle: the top compartment holds the class name, the middle holds attributes (each prefixed with a visibility symbol), and the bottom holds methods. Class diagrams are the primary tool for object-oriented design and are used to plan domain models, define API types, map database schemas, and document existing codebases.
- When should I use a class diagram instead of an ERD?
- Use a class diagram when your concern is object-oriented design: you need to model behaviour (methods), enforce encapsulation (visibility), represent inheritance hierarchies, or capture interface contracts. Use an ERD when your concern is purely relational storage: tables, columns, primary keys, foreign keys, and normalisation. In practice, class diagrams drive the code and ERDs drive the database schema — the two diagrams often co-exist on the same project and address different audiences.
- What do the visibility symbols +, -, #, and ~ mean in a class diagram?
- These are UML visibility markers placed before each attribute and method name.
+(public) means accessible from any other class.-(private) means accessible only from within the class itself.#(protected) means accessible from the class and any of its subclasses.~(package) means accessible from any class in the same package or namespace. Correct visibility notation encodes access control decisions that have direct implications in generated code. - What is the difference between association, aggregation, and composition?
- All three are "has-a" relationships, but they differ in coupling strength. Association (solid line with open arrowhead) is the weakest: one class holds a reference to another, but neither owns the other. Aggregation (hollow diamond at the whole end) is a whole/part relationship where parts can exist independently — a Department aggregates Employees, but an Employee survives if the Department is dissolved. Composition (filled diamond at the whole end) is a strong whole/part relationship where parts cannot exist without the whole — an Order is composed of OrderItems; deleting the Order deletes all its items. If the child's lifecycle is fully controlled by the parent, use composition; if the child can exist independently, use aggregation or association.
- What is the difference between a class diagram and an object diagram?
- A class diagram shows the blueprint: the types, their structure, and their static relationships — what kinds of objects can exist. An object diagram shows a snapshot: specific named instances of those classes at a particular point in time, with actual attribute values and actual links between instances. Object diagrams are useful for illustrating a specific scenario or debugging a design. In practice, class diagrams are far more common; object diagrams are used selectively to clarify a structural scenario that is difficult to reason about from the class diagram alone.
- What are the best practices for UML class diagrams?
- Keep each diagram to 8–12 classes — split larger models into packages. Show visibility symbols on all attributes and methods. Add multiplicities to both ends of every association. Name associations with verb phrases from the source-class perspective. Use composition only when the child's lifecycle is genuinely controlled by the parent. Mark interfaces with the «interface» stereotype. Draw realization arrows from concrete classes to the interfaces they implement rather than leaving the contract implicit.
- How does AI generate class diagrams in flow-chart.io?
- When you describe a domain in plain language, flow-chart.io parses the description and produces a typed scene graph — not an image. Each class becomes a three-compartment box with the correct visibility symbols; each relationship becomes a typed connector (association, composition, inheritance, realization) with the correct UML arrowhead and multiplicity labels. A layout pass then arranges inheritance hierarchies top-to-bottom, minimises line crossings, and positions classes to make the model readable. Because the output is a structured scene graph, every element remains fully editable: rename a class, add an attribute, change a relationship type, or adjust multiplicities — without regenerating from scratch.