The canvas

Working in the diagram canvas — placing and arranging elements, connections, the containment tree and zoom, and controlled, versioned editing.

The canvas is where you build and arrange the model. It’s a working modeling surface, not a freehand drawing board: what you place are real model elements, and how you change them is governed.

Placing and arranging elements

You add elements to a diagram and position them on the canvas, then connect them to express relationships. Because elements are part of the model, the same element can be brought onto other diagrams later — placing it here doesn’t lock it to this one view. Alignment tools help keep a diagram tidy and readable as it grows.

Connections

Elements are joined by connectors appropriate to the diagram — composition and generalization on a structural view, flows on a behavioral one. Connectors are model relationships, so the links you draw carry real meaning and show up consistently wherever the elements appear.

Finding your way around

For large models, the canvas provides navigation aids — a containment tree that shows the model’s structure as a hierarchy, and zoom to move between a detailed view and the big picture. The diagram browser can be filtered to find the diagram you want.

Controlled editing

Editing the model is controlled. When the element is in a controlled state and its metaclass calls for it, the canvas asks for a reason for change — a short note such as the change request it implements — which becomes part of the model’s history. Where those conditions aren’t met, no reason is requested. As with other controlled records, this is what makes architectural change attributable rather than anonymous.

Versioning with commits and baselines

The model is versioned through commits: you describe what changed, and that description is recorded with the change, building a readable history of how the architecture evolved. At milestones, a baseline can be taken of the scope you select — not automatically the whole module — as a named snapshot you can return to and compare against. This gives architecture the same demonstrable, point-in-time evidence the rest of the platform provides.

Next

With the canvas in hand, the next articles cover the model elements and stereotypes you place on it, the ports and interfaces that connect them, and how the model links back to requirements.

Was this helpful?