# 3 · Diagrams & views

ASysT draws several **kinds** of diagram from the same model, and it honours the **views** your model
itself declares. You don't draw diagrams by hand — you choose what to look at, and ASysT renders it.

---

## The diagram kinds

Depending on what your model contains, ASysT can render:

| Kind | Shows | From SysML |
|------|-------|-----------|
| **Block definition (BDD)** | Definitions/parts and their relationships | `part def`, `:>`, composition, … |
| **Internal block (IBD)** | A part's internal structure + port connectors | parts with internal parts / `connect` |
| **State machine** | States, transitions, guards/triggers, entry/do/exit | `state def`, `transition` |
| **Action Flow** | Actions, object/control flow, decisions, loops and swim lanes | `action def`, `flow`, succession, `allocate` |
| **Sequence** | Lifelines and time-ordered messages (a linear timeline) | interactions / message passing |
| **Requirements table** | Each requirement with what satisfies / verifies it | `requirement`, `satisfy`, `verify` |
| **Element table / matrix** | A tabular view of elements, or a relation matrix | view-driven |
| **Use case** | Actors and use cases, `include` | `use case`, `actor` |

ASysT picks the appropriate renderer for what you're viewing; some kinds (IBD, sequence, tables) are
reached from the toolbar or by opening a specific element.

## Anatomy of a diagram — the words for what you see

A few names recur across this manual. They split into two groups: parts of the **model** (drawn from your
`.sysml`) and parts of the **canvas** (presentation chrome ASysT adds). Open **CrisisSystem's internal
structure** to see them all together.

| Term | What it is | From the model? |
|------|-----------|:---:|
| **Node** (box) | A model element drawn as a box — a `part def`, a `part` usage, a state, an action. | ✅ |
| **Compartment** | A stacked section inside a node — its name/stereotype, attributes, etc. | ✅ |
| **Port** | A typed connection pin on a node's border (a SysML `port`), shown as a small square + its name. | ✅ |
| **Connector** | The line joining two parts — a SysML `connection` / `connect a.x to b.y`. (We say *connector* for the line, to keep it distinct from the snap points below.) | ✅ |
| **Frame** | The labelled border around every rendered view. Its heading is `«view» Name`; a model-declared view also shows its real `: ViewDef`. | — |
| **Marker** | The small icons on a box that navigate — 📦 drill in, 📜 definition, 🔄 state machine, ▶️ action flow, ⇄ sequence, ☰ requirements, 🔍 find usages, 🔭 views, 🎭 use cases, ƒ constraints, 📌 allocation. Extras fold under `⋯`. The full list is in [Navigating models](02_Navigating_models.md). | — |
| **Handle slot** (a.k.a. **snap point**) | A perimeter anchor a connector endpoint can attach to. There are **nine per side**, and how many are exposed depends on box size — three on a short edge, five at the default width, all nine once the edge is large enough to keep them apart. | — |
| **Handle ring** | The full set of handle slots all around a box — revealed as you hover or drag an endpoint. | — |
| **Note** | A free canvas note or a model `comment`/`doc`/`rep` shown through the same visual surface. Model annotation text is semantic; colour, link and geometry are presentation. | mixed |
| **Image** | A model-scoped uploaded picture drawn as a draggable, resizable node. Its bytes stay in `Images/`; its placement and size stay in the rendering. | — |

> **Naming note.** In the code these anchors are `handle`s (React Flow's term, and the saved-file key
> `sourceHandle`/`targetHandle`); in this manual we call them **snap points** so they're not confused with a
> SysML **connection**.

**Re-routing a connector.** Drag a connector's **endpoint** off a port and drop it on any **snap point** on
the same box — the connector re-routes there (it never changes *which* two parts are joined, so your model is
untouched). The choice is saved with the [rendering](02_Navigating_models.md#saved-renderings), so it comes
back when you reload it.

## Model-declared `view`s

SysML v2 lets a model declare its **own** views — `view def`, `view … { expose …; render …; }`. These
are the diagrams the *author intended*. ASysT reads them and offers them directly: choosing a model view
shows exactly the elements it `expose`s, drawn in the `render` style it asks for. A view can also name
the **viewpoint** (stakeholder concern) it answers — so a view reads as "the safety engineer's view",
not just a bag of elements.

This is the difference between **renderings** (finite, tool-provided drawing styles) and **views**
(free-form selections your model defines). ASysT ships the rendering styles; your model brings the views.

For example, a declared `view carOverview : GeneralView` is framed exactly as
`«view» carOverview : GeneralView`. If a file declares only `package CarIBD`, ASysT does not invent a
model view declaration: it opens a tool-generated General View framed `«view» CarIBD`, with a small
`general view` kind badge. The package box remains visible inside that outer view frame.

## Renderings (drawing styles)

A **rendering** is *how* something is drawn — e.g. a state machine as a state diagram, a set of elements
as a table, an activity as swim-lanes. When a model view says `render as …`, ASysT honours it on both the
on-screen canvas **and** the static export. You don't configure renderings; you choose a view (or a
diagram kind) and the right rendering follows.

## Coming back to a picture you liked

There is no "preset" to configure. What ASysT saves is a **rendering** — the whole arrangement of one
diagram under a name you choose — and it reopens by itself the next time you arrive at that diagram. See
[Saved renderings](02_Navigating_models.md#saved-renderings).

---

Next: [Checking your model](04_Validation.md) — read the bundled parser's diagnostics and understand
what a quiet check does and does not prove.
