Class Diagrams & Data Models
Design the structure of a system — the classes, what they hold, how they relate — and the tables underneath it, as boxes you and the agent both edit, on the same canvas as everything else.
A sequence diagram shows what happens in what order. A class diagram shows what exists and how it is built: which things inherit from which, which contain which, which merely know about which. When you are designing a system, refactoring one, or trying to understand code someone else wrote, that picture is the one you keep reaching for — and it is the one every design-patterns book draws its patterns in.
Circuitry gives you both the drawing and the text behind it. You drop classes from the palette and fill them in, or the agent draws the whole design from your description or from the code, and either way the diagram stays an object on the canvas that reads back as text the agent can check, edit and re-send.
Where they live
Like a sequence diagram, a class diagram or data model is drawn on a Workflow canvas, which includes a whiteboard. It gets everything the canvas has: selection, the Style panel, undo, copy and paste into another document, and the drawing layer for annotations by hand.
The parts of a class diagram
| Part | What it is |
|---|---|
| Class | A box with three compartments: the name (with an optional stereotype such as «interface» or «abstract» above it), the attributes, and the methods. |
| Member | One line in a compartment, written the way you would in code: a visibility mark (+ public, − private, # protected, ~ package), then the name and type. A method has parentheses. An abstract member is shown in italics; a static one is underlined. |
| Relationship | A line between two classes with a head that says what kind: a hollow triangle for inheritance, a filled diamond for composition (the part cannot exist without the whole), a hollow diamond for aggregation, an open arrow for association, and a dashed line for a dependency or an interface being realised. |
| Multiplicity | A small 1, * or 0..1 beside either end of a relationship. |
| Note | A folded-corner box attached to a class with a dashed line — a remark meant to be seen on the diagram. |
| Namespace | A group of classes that share a colour band. |
Notice what the layout does with a hierarchy: whatever order you write the lines in, the parent ends up above its children and the interface above what implements it, because that is the axis you read a design along. Associations and composition run sideways between peers.
A data model (entity-relationship diagram) uses the same machinery with different boxes: an entity is a name over a list of typed attributes, each marked as a primary key, foreign key or unique key where it is one, and a relationship carries crow's-foot cardinalities at each end — exactly one, zero or one, zero or more, one or more.
Draw one by hand
1. Drop a class from the palette
Open the Flow shapes in the nodes panel and expand them. Under the shapes is a Structure row: Class, Interface, Abstract, Entity, Note and Actor. Drag one onto the canvas. It arrives as a real diagram box — a name, an empty attributes compartment, an empty methods compartment — and its name opens for editing.
(The Actor is the odd one out: it is a stickman for a sequence diagram, and dropping it creates the participant with its lifeline already hanging below.)
2. Fill in the members
Select the box and open its config panel. There you edit the name, choose a stereotype, set a generic type parameter, and type the attributes and methods one per line, exactly as they will appear. The box resizes itself to fit. An entity's panel has one list of attributes instead — type name, then PK, FK or UK if it is a key, then an optional comment in quotes.
Write members the way you would in code: + public, - private, # protected, ~ package. A method has parentheses. End one with * to mark it abstract (it draws in italics) or $ for static (underlined).
3. Connect the classes, then say what the line means
Drag a connection between two boxes the way you connect any two nodes. It arrives as the ordinary case — an association between classes, one-to-one between entities — so the picture and the written form agree from the moment you let go.
Then select the line. The selection toolbar gives you the whole vocabulary:
| Button | What it does |
|---|---|
| Type | Inheritance, Realization, Composition, Aggregation, Association, Dependency, or a plain link. The button is labelled with what the line currently is. |
| Multiplicity | A 1, 0..1, * or 1..* at either end, or none. |
| Label | The words on the line. |
| Flip | Turns the relationship round. This reverses the sentence, not just the arrowhead — the parent and the child swap, and the diagram re-reads accordingly. |
| Delete | Removes the line, leaving both boxes. |
On a data model the same toolbar offers This end and That end — exactly one, zero or one, zero or more, one or more — and an Identifying / Non-identifying toggle, which is the dashed line.
4. Edit a box from the toolbar
Select a class and the toolbar offers Attribute and Method, which append a line and open the panel for you to type it, plus Stereotype (the button shows the current one), Name diagram, and Delete. An entity gets Attribute. It means a whole diagram can be built without touching the text once.
5. Keep notes with a class
Every class and entity box has a Notes field in its config panel. Use it for what the box means: the invariant it protects, the decision behind it, the thing the next person needs to know. Notes stay with the box, are not drawn on the canvas, and come back to the agent every time it reads the diagram — so they are also the place to leave instructions for it.
Let the agent draw it
Describe the design — "draw the Observer pattern for our price feed", "show me the classes in this folder and how they depend on each other", "model the tables for orders, line items and payments" — and the agent draws it. A class hierarchy is laid out with the parent on top, whichever way the relationship was written; interfaces and their implementations, wholes and their parts, follow the same rule, so the picture reads the way the pattern is drawn in the book.
The agent can draw every Gang-of-Four pattern as it appears in the literature — Strategy, Observer, Composite, Decorator, Abstract Factory, Command and the rest — which makes it a fast way to talk about a design: ask which pattern fits, have it drawn, then have it drawn again with your class names in it.
Analysing code
When the agent draws a diagram from code, it names the boxes by the real identifiers so the diagram is a map you can search, and stamps it with the files it read and the commit it read them at. Before it trusts or updates the diagram later, it checks whether those files have changed since — so a diagram of your code tells you when it has gone stale instead of quietly lying.
The text behind the picture
Every diagram has a written form. Ask the agent to read a diagram back and you get it as text: the classes with their members, the relationships with their heads, the notes. Edit that text — rename a class, add a method, turn an association into a composition — and send it back, and the boxes update in place: a class keeps wherever you dragged it, only what changed changes, and anything on the canvas the text no longer mentions is reported to you rather than deleted.
Give a diagram a title in that text and several can share one canvas — the domain model beside the service layer beside the pattern you are considering — each addressed by its name.
Related
- Flowcharts — steps, decisions and loops
- Sequence Diagrams — what happens, in what order, on whose side
- Tips for working with diagrams — drawing a real run from its logs, and keeping a diagram worth trusting
- The Smart Whiteboard — thinking, planning and directing on a canvas
- Workflows Overview — the canvas these are drawn on
- Coding Agent — directing an agent alongside your code