SysML Diagrams

Holarch draws the SysML diagram types as views of the same LML model that every other page uses. A block is an Asset, a part is a decomposed-by child, a connector is a Conduit, a constraint block is an Equation and a state is a labelled Characteristic. Nothing on a SysML diagram is stored only in the picture: every box, port, compartment row and line is an entity or a relationship, so the Database, the Interface Register, Budgets, the RVTM and the Simulator see the same data.

This page covers ten diagram types:

For the canvas, zoom, toolbar groups, export, annotations and thumbnails that every diagram shares, see Diagrams. The Action Diagram and the FFBD are covered in Action Diagrams and Functional Analysis.

Concepts

Diagrams are views, not drawings

Each SysML diagram has a root entity and draws what the model says about it. Adding a block from the palette creates an Asset and the relationship that places it (for example decomposed by). Removing a shape with Remove from Diagram drops that relationship; the entity stays in the database. Delete from Database deletes the entity everywhere. Layout (positions, sizes, which compartments show) is saved per diagram and per root, and every change, including a move, is one undo step.

Because the diagram reads the model, the same Asset can appear on a BDD, an IBD, an Asset Diagram and a Physical I/O Diagram at once. An edit in one view shows in all of them.

How SysML maps to LML

Diagram-managed relationships

On the board-style diagrams (BDD, IBD, Class, Package, Parametric, State Machine, Use Case, Requirement), the relationships the diagram draws are locked in the inspector's Relationships tab while the diagram is open. Change them on the canvas instead, so the drawing and the model cannot disagree.

How to use it

When and why

SysML diagrams answer architecture and design questions after the requirements and functions exist:

• Use Case Diagram at concept definition: who uses the system, for what, and where the system boundary is. Use it with stakeholders before writing system requirements.
• Requirement Diagram during requirements analysis and at reviews: how one requirement is derived from others, and which blocks, functions, constraints and test cases satisfy or verify it.
• Block Definition Diagram after functional analysis, when you allocate functions to a physical structure: the system breakdown, the value properties you will budget and the operations each block performs.
• Internal Block Diagram during interface design: which parts connect, through which ports, carrying which items. It feeds the Interface Register and the ICD.
• Parametric Diagram during design analysis and trade studies: the equations that tie block values together (power, mass, link budgets), checked with units.
• State Machine Diagram for operational modes and fault behavior of a block.
• Activity and Sequence Diagrams for behavior: the same action flow as the Action Diagram, in SysML notation, with swimlanes or lifelines.
• Package Diagram to organize a large model into packages and record import dependencies.
• Class Diagram for software structure, including import from Java source.

Open a SysML diagram

1. Open Diagrams at the bottom of the rail and choose + Create Diagram ▾, or select an entity anywhere and use its Open ▾ menu.
2. Choose the diagram type. The root must fit the type: an Asset for BDD, IBD, Package, Class and State Machine; an Equation for Parametric; an Action for Use Case, Activity and Sequence; a Statement or Requirement for the Requirement Diagram.
3. The diagram opens fitted to the window. The palette is on the left with the tabs New, Existing and Layout; the inspector opens on the right when you select something.

To switch the same root to another diagram type, use the type selector in the top bar.

Build a block structure (BDD)

1. Open a Block Definition Diagram on the system Asset. Holarch adds the Block label to the root.
2. Drag Block from the New tab onto the root block. Result: a new Asset "New Block" appears below the root, joined by a composition line (filled diamond at the root end).
3. Select the new block; in the inspector, change its name and number.
4. Drag Value onto a block. Result: a Values compartment row "New Characteristic: —" appears. Select the row, then set the Value (for example 2.1 kg) and Units in the inspector.
5. Drag Operation onto a block for each function the block performs; drag Input Parameter or Return Type onto an operation row to add its parameters.
6. Drag Port onto a block to add a port on its border. Set the port's Direction in the inspector.
7. To relate two blocks without composition, select one, drag a green handle onto the other and release over Simple Association (connected by).
8. Use Levels to show more decomposition levels and View ▾ to hide ports, values, constraints or operations.

Define interfaces (IBD)

1. Open an Internal Block Diagram on a subsystem Asset. Its parts and ports appear nested inside the root frame.
2. Drag Block onto the root (or into a part) to add a part; drag Port onto a part's border to add a port.
3. Select a part or port, drag a green handle onto another part or port and release over Connect (onto a port) or Connect To Block. Result: a Conduit "new connector" joins them.
4. Select the connector. In the inspector:
   • Set Item Flow (Undirected, Directed, Reverse or Bidirectional).
   • Under Conveyed Items (Item Flows), click a suggestion under Exchanged by the ends or use + Add Item ▾ to add the Input/Outputs the connector carries.
   • Set Interface Status, Owner and TBD/TBR, and use + Link Requirement… for interface requirements.
   • Read the Capacity Check; set the Conduit's Capacity and Units in its attributes to enable it.
5. Click Interface Register in the toolbar to list every connector on the diagram, and Export CSV from there.

Analyze with constraints (Parametric)

1. Create an Equation for the analysis (for example "Power Budget") and open a Parametric Diagram on it.
2. Drag Constraint (Equation) onto the canvas. Select it and type its equation in the Value attribute, for example P_gen = A*Eta*S*cos(Theta).
3. Drag Parameter (Characteristic) onto the constraint once per variable and name each parameter exactly as in the equation (P_gen, A, Eta, S, Theta). Set Units on parameters where it helps.
4. Drag Block (Asset) onto the canvas (or from Existing), and drag Value (Characteristic) onto it, or bring blocks in through their bound values.
5. Select a parameter port, drag its handle onto a block value row and release (Bind). Result: a binding line runs from the parameter to the value.
6. Read the badge on each constraint (✓ OK, ↻ Solve, ✓ Pass, ✕ Fail, … Needs input, ⚠ Error). Point at a badge for the details.
7. Click Solve All. The dialog lists every value that would change and the state of each constraint. Click Apply N Changes to write them as one undo step.

Model modes (State Machine)

1. Open a State Machine Diagram on the Asset whose modes you model.
2. Drag Initial State, State and Final State onto the canvas. Drag a State into another state to make a composite state.
3. Select a state, drag a handle onto the next state and release over Transition. Result: a Transition "New Transition" with an open arrow.
4. Select the transition and set Trigger (name), Guard, Trigger Type and Effect in the inspector. The label reads name [guard] / effect.
5. Drag Entry Action, Do Action or Exit Action onto a state to add its behaviors.
6. For concurrent behavior, drag Parallel State (it starts with two regions) and drag states into its regions.

Capture use cases

1. Create an Action for the system's use (for example "Operate EO-1 System") and open a Use Case Diagram on it.
2. Drag System Boundary onto the canvas; double-click it to set its title; drag its blue corner to resize.
3. Drag Use Case into the boundary for each use case and Actor beside it for each user or external system.
4. Connect an actor to a use case (Performs), or two use cases (left half <<Include>>, right half <<Extend>>).

Trace a requirement (Requirement Diagram)

1. Open a Requirement Diagram on a requirement or a section. It shows the root, its children to the chosen Levels, and everything linked to them by a trace relationship.
2. Drag Asset, Action or Test Case onto a requirement. Result: the element appears with a «satisfy» (Asset, Action) or «verify» (Test Case) arrow to the requirement.
3. Connect two requirements and choose Containment (decomposed by) or Trace (traced to); change it later with Paths ▾ to «deriveReqt», «refine» or «copy».
4. Use Attributes ▾ to choose which requirement attributes the boxes show.

Worked example: the CubeSat EO-1 power subsystem

Create the demo with Manage Projects → Project Files ▾ → Create Demo Project. It contains a SysML diagram of every main type.

1. BDD of EO-1 Spacecraft (1). Open Open ▾ → Block Definition Diagram on EO-1 Spacecraft. It shows the six subsystems (Payload Camera, ADCS, EPS, C&DH, Communications, Structure and Thermal) at Level 1 with their values: Launch Mass: 10.4 kg, Battery Capacity: 77 Wh, Downlink Rate: 10 Mbps. Operations are hidden with View ▾ → All Operations. Set Levels to Level 2: the EPS parts (Solar Arrays, Battery Pack, Power Distribution Unit) appear; the Solar Arrays line shows multiplicity 2.
2. IBD of EPS (1.3). Open the Internal Block Diagram on EPS. Solar Arrays, Power Distribution Unit and Battery Pack sit inside the EPS frame, with the boundary port 12 V Bus (direction Out) on the right edge. The connectors are Array Power (IF-20), Battery Power (IF-21, both ways) and Regulated Bus (IF-22). Select Battery Power: Item Flow reads Bidirectional because both ends are origins.
3. Parametric of EPS Power Budget (EQ-1). Open the Parametric Diagram on EPS Power Budget. Solar Power Generation holds P_gen = A*Eta*S*cos(Theta); its parameters bind to Cell Area (0.2 m^2), Cell Efficiency (0.295) and Peak Array Power on Solar Arrays, and to Solar Flux (1361 W/m^2) and Sun Incidence Angle (0.35 rad) on Orbit Environment. Battery Depth of Discharge holds DoD = E_ecl/C_bat, bound to the Battery Pack values.
   • Select Cell Area on Solar Arrays and change its Value to 0.22. The Solar Power Generation badge changes to ↻ Solve.
   • Click Solve All. The dialog shows Peak Array Power changing to about 83 W (0.22 × 0.295 × 1361 × cos 0.35), How = Computed. Click Apply 1 Change.
   • To check requirement 3.1 (28 W orbit-average), drag Constraint (Equation) onto the canvas, set its Value to P_gen >= 28[W], drag Parameter (Characteristic) onto it, name it P_gen and bind it to Peak Array Power. The badge reads ✓ Pass.
4. State machine of EO-1 Spacecraft. Open State Machine Diagram on EO-1 Spacecraft: Initial → Launch → Detumble → Nominal Imaging ⇄ Downlink Contact, with Undervoltage [bus < 6.4 V] (Change Event) into Safe Mode, Recovery Command back out, and End of Mission into Decommissioned. Safe Mode shows do / Orient Arrays to Sun.
5. Use cases of Operate EO-1 System (UC). The EO-1 Mission System boundary holds six use cases. Imagery Customer performs Request Imagery and Receive Image Products; Mission Operator performs the others. Collect Imagery «include» Plan Imaging Campaign; Recover from Safe Mode «extend» Monitor Spacecraft Health.
6. Requirement diagram of 3.1 Orbit Average Power. 3.1 shows «deriveReqt» to 1.5 Daily Collection Volume, and «satisfy» arrows from Solar Arrays, function F3 and the constraint EQ-1.1.
7. Sequence of Run Nominal Imaging Pass (OPS). Open Sequence Diagram on Run Nominal Imaging Pass: lifelines Ground Station, UHF Transceiver, C&DH, ADCS, Payload Camera, S-band Transmitter, Power Distribution Unit and Mission Operations Center; Imaging Plan passes from Ground Station to UHF Transceiver; the loop Each target ×4 and the alternative Contact in view? appear as loop and alt fragments.

Tips and good practice

• Model first, then draw. If the Database already holds the structure (for example from an import), open a BDD or IBD and set Levels; the diagram draws itself.
• Name parameters exactly as the equation does. A name in the equation that is not a parameter of that constraint is an error: "x" is not a parameter of this constraint.
• Put units on values, not only numbers: 12 kg, 150 ft/min. The parametric solver converts units and reports dimension errors.
• Use multiplicity on compositions. The Multiplicity you set on a composition line is the count that Budgets and Rollup use.
• Type ports with interface blocks. Set a port's Type; use Create Port when connecting a port to a block to get the conjugated counterpart automatically.
• Prefer Remove over Delete. Remove from Diagram (Default) only drops the relationship that placed the element. Use Delete from Database only when the entity is wrong everywhere.

Common mistakes

• A new block disappears after you drop it on the empty canvas. On a BDD, a block dropped on empty canvas is kept as a free block and you see Block added. Connect it to another block to place it in the model. On other diagrams an entity that no relationship places is not shown: Not shown: X is saved but not connected to this diagram. Drop onto a parent, or connect it.
• The connect gesture is refused. A red frame on the target means no relationship fits, for example a transition into an initial state. Read the message and connect a valid pair.
• A constraint shows … Needs input. At least two of its variables have no value. Bind the parameters to values that hold numbers, or give the parameters values.
• A constraint shows ⚠ Error "The result is power, but P_gen is in kg". The bound value's Units do not match the equation's dimension. Fix the Units or the equation.
• The sequence diagram shows "Unallocated (missing performed by Asset)". Some actions have no performer. Relate them to an Asset (drag them onto a lifeline in the Activity Diagram swimlanes, or set performed by).

How it connects to other features

• Functional analysis → BDD/Activity. Functions from Functional Analysis are Actions; allocate them to blocks with performs and they appear as operations on the BDD and as swimlane content on the Activity Diagram.
• IBD → Interfaces. IBD connectors are the Conduits listed in the Interface Register, the Interface Control Diagram and the ICD document export (Other Diagrams, Interfaces).
• BDD values → Budgets. Value properties are Characteristics; Budgets & TPMs roll them up with the composition multiplicities (Budgets & TPMs).
• Parametric → Requirements. Constraint Equations can satisfy requirements (EQ-1.1 satisfies 3.1), so the RVTM and the Requirement Diagram show the analysis.
• Activity and Sequence → Simulator. Both edit the same flow as the Action Diagram, which the Simulator runs. ▶ Simulate ▾ on the Activity Diagram opens it.
• Every diagram → documents and presentations. Diagrams render into documents, review packages and slides, and export as PNG, SVG, HTML and DOCX (Diagrams).

The SysML editor

BDD, IBD, Class, Package, Parametric, State Machine, Use Case and Requirement Diagrams share one editor. The Layer, Physical I/O and Interface Control Diagrams use it too (other diagrams). The Activity and Sequence Diagrams have their own editors, described in their sections.

Toolbar

The type's own buttons come first, then these shared controls (shown only where the type uses them):

The SysML frame is drawn around the content with a header kind [Class] Name, where kind is bdd, ibd, par, stm, uc, req, pkg or act. For example: bdd [Asset] EO-1 Spacecraft. Frame settings are shared by all frame-capable diagrams of the same root.

On the BDD and IBD, ⚙ adds Show Pictures / Hide Pictures, which draws each block's picture (the entity image) at the bottom of the box.

Palette

• New tab: the type's fixed items under Drag onto the diagram. Point at an item for where it can go ("Drop onto a block", "Drop anywhere on the diagram").
• Existing tab: Search entities… lists matching entities of the classes the diagram accepts (up to 200, by number). No matches. when nothing fits.
• Layout tab: Layout options, with the same items as Layout ▾.
• Drag an item onto the canvas or onto a target shape. The shape under the pointer highlights. Focus an item and press Enter or Space to insert it at the center of the view.

Canvas gestures

Inspector

• Shape selected: the entity panel (name, number, description, attributes, relationships, metadata, comments) with Delete…. On the IBD, a port also shows Type and Conjugated; a connector shows the interface section.
• Line selected: a Relationship panel with the two ends and the kind (for example Composition (decomposed by)), Paths (relationship type), the line's own entity (a Conduit, Logical or Transition) with Properties…, the relationship attributes the type exposes (for example EPS's Multiplicity), the type's extra fields, and Delete….

Delete and remove

Delete, Backspace, Delete or Delete… opens Delete "Name":

• Remove from Diagram (Default) removes the element from this diagram and drops the relationship that placed it there; the entities stay in the database.
• Delete from Database permanently deletes the entities and all their relationships. On the BDD, deleting a block also deletes its ports, values, constraints, operations and their parameters.
• Both can be undone with ⌘Z. Cancel closes the dialog.

Block Definition Diagram

Blocks and their features. The root Asset gets the Block label when the diagram opens.

What it shows

• The root and the blocks reachable within Levels through decomposed by, related to and associations, plus free blocks you placed. Ports and states are not drawn as blocks.
• Each block is a «block» box with compartments:
  • Values: name: units (or the value, or —) for each Characteristic the block is specified by.
  • Constraints: name { equation } for each Equation the block is equation of.
  • Operations: name(param: Units, …) : return for each Action the block performs; a parameter without Units shows Any.
• Ports as small squares on the border with a direction glyph: In (arrow in), Out (arrow out), In and Out (both), none.
• Lines: composition (filled diamond at the whole, open arrow at the part, part multiplicity at the part end), aggregation (open diamond), association (plain line labelled with the Logical's name and both multiplicities).

Toolbar and palette

• Levels, View ▾ (All Ports, All Values, All Constraints, All Operations), Frame ▾, Paths ▾, Delete, Layout ▾.
• New: Block, Port, Value, Constraint, Operation, Input Parameter, Return Type.
• Existing: Assets, Characteristics, Equations, Actions and Input/Outputs.

An existing entity dropped from the Existing tab goes to the slot that matches its class.

Connecting

From a block to another block: Composition (decomposed by) or Simple Association (connected by). Only the association is offered when the target is already a part, or when the composition would create a cycle. A simple association creates a Logical "A connects to B" with Multiplicity 1..1 on both ends.

Paths ▾ on a composition, aggregation or association line offers Composition, Aggregation and Simple Association. The composition's inspector shows Part's Multiplicity; the association's shows both ends' multiplicities.

Internal Block Diagram

The parts and ports inside a block, with the connectors between them and the items they carry.

What it shows

• The root as a large container with its parts nested inside, to Levels deep (default 3). Parts are child Assets (not ports, not states).
• Ports on the borders of the root and of each part, labelled name : Type, name : ~Type when conjugated, or the plain name.
• Connectors: Conduits whose two ends are shown. The label is the Conduit name plus [Interface Status] when set. An over-capacity connector turns red with ⚠ over capacity; a unit mismatch turns orange with ⚠ unit mismatch.
• Item flows: the Input/Outputs each connector transfers, in green italics, with a triangle for direction. The direction comes from the performing actions (an action on one side generates the item, an action on the other receives it), else from the port directions, else from the connector's Item Flow setting. A circle means the direction is not set. Point at an item flow for "Item flow (forward): …".

Toolbar and palette

• Interface Register lists the diagram's connectors with Interface, Endpoints, Status, Owner, TBD/TBR, Items, Requirements and Capacity, status counts, and All Conduits in the project. Export CSV downloads it.
• Levels, View ▾ (Item Flows), Frame ▾, Delete, Layout ▾.
• New: Block (a new part, numbered under its parent) and Port (onto a block). Existing: Assets. Dropping an existing Asset into a part adds it there and keeps its other parents; Already on the diagram there. if it is already a child.

Connecting

• To a port: Connect. To a block: Connect To Block. Both create a Conduit "new connector" with both ends connected by it.
• From a port to a block, a second zone Create Port adds the counterpart port on the target block (same name and type, Conjugated flipped, Direction reversed) and connects the two.
• Cannot connect an element to itself. and These elements are already connected. refuse duplicates.

Connector inspector

The capacity check sums each conveyed item's Data Rate (in Data Rate Units), or its Size (in Units), converted to the Conduit's Units, and compares the total with the Conduit's Capacity.

Port inspector

• Type: Set Type… picks an Asset (it gets the Interface Block label) or an Input/Output; Change… and Clear. Untyped when none.
• Conjugated (reverse the type's flows; shown as ~Type).
• Direction in the attributes: None, In, Out, In and Out.

Parametric Diagram

Constraint blocks with parameters bound to block values, evaluated with units. The root is an Equation; its child Equations are the constraints. If the root's own Value is an equation (it contains =, < or >), the root is a constraint too.

What it shows

• Constraints: rounded «constraint» boxes with the name, the equation in braces and a status badge. Parameters are small ports on the border labelled name: units.
• Root parameters: Characteristics the root has variable, in a column on the left. Every constraint can use them by name.
• Blocks: «block» containers holding value boxes (name, value and units). A block appears automatically when one of its values is bound to a parameter; add others with Block (Asset).
• Binding connectors: lines from a parameter to the value it is bound to.

Toolbar and palette

• Solve All evaluates every constraint, solves single unknowns, checks inequalities and previews the values to write.
• Solve does the same for the selected constraint only (with no constraint selected it acts like Solve All).
• Frame ▾, Delete, Layout ▾.
• New: Constraint (Equation), Parameter (Characteristic) (onto a constraint; onto the canvas for a root parameter; onto a block it becomes a value), Block (Asset), Value (Characteristic) (onto a block). Existing: Equations, Characteristics and Assets.
• Connect: drag a parameter's handle onto a value; the only zone is Bind (related to). Drop a parameter onto a block value. when released elsewhere.

How the network is solved

1. Each constraint's equation is parsed. Every name in it must be a parameter of that constraint, a root parameter, or a constant (PI, pi, E, g0 = 9.80665).
2. A parameter's variable is its bound block value when it has one; otherwise the parameter's own Value. Two constraints that bind to the same value share it, which links them into a network.
3. An equation of the form y = expression, where y is a parameter that does not appear on the right, defines y. The first definition of a variable drives it; later ones become checks.
4. Definitions are computed in dependency order. Loops are iterated until they settle (up to 200 passes).
5. An equation with exactly one unknown input is solved numerically for it.
6. Remaining equations and inequalities (<=, >=, <, >, !=, ==) are checks, with a relative tolerance of 10⁻⁶.
7. A new value is written as a number when the value has its own Units attribute that matches; otherwise as text with a unit (83.0 W).

Badges

Solve dialog

Solve All Constraints (or Solve Constraint) shows "N values will change:" with the columns Value, Parameter, Current, New and How (Computed or Solved for input), then a Constraints table with each constraint's state (Computed, Solved for input, Pass, Fail, Needs input, Error) and message. Apply N Changes writes the values as one undo step (Updated N values). With nothing to change: No values change. Every computed value is up to date. and Close.

Units and expressions

• Values with units: 12 kg, 3.5 W, 150 ft/min, $1.2M. Inside an equation, put a unit in brackets after a number: 9.81[m/s^2], 28[W].
• Operators: + - * / ^ and parentheses.
• Functions: sqrt, abs, sin, cos, tan, asin, acos, atan, atan2, exp, log, ln, log10, pow, min, max, floor, ceil, round. Trigonometric functions need a plain number or an angle.
• Units: length (m, in, ft, yd, mi, nmi, mil, au, ly), mass (g, t, lb, oz, slug, ton), time (s, min, h, d, wk, mo, yr), speed and acceleration (mph, kph, kn, fps, gn), force (N, lbf, kgf, dyn), power and energy (W, hp, J, Wh, cal, BTU, eV), pressure (Pa, bar, atm, psi, ksi, torr, mmHg, inHg), electrical (A, V, Ω/ohm, Ah), frequency (Hz, rpm), data (bit/b, B, KB, bps, Bps, Kbps), angle (rad, deg/°, arcmin, arcsec, rev), temperature (K, °C, °F, °R, and the differences Δ°C, Δ°F), area and volume (ha, acre, L, gal, qt, pt, floz, cc), amount (mol), ratios and counts (%, ppm, ppb, ea/each/pcs/count) and cost ($ or USD, $K, $M, $B).
• Prefixes: SI prefixes from atto to yotta on the units that take them (kW, mA, GB, µs), binary prefixes Ki, Mi, Gi, Ti, Pi on bit and byte, and unit names (meter, kilowatt, hours).
• Dimension checks: adding mass to power is an error; the result's dimension must match the bound value's Units.

State Machine Diagram

States and transitions of an Asset (or of a Characteristic used as a composite state).

What it shows

• Top states: Characteristics labelled State that the root Asset is specified by (for a Characteristic root: its decomposed by children).
• Initial state: filled circle; final state: bullseye; history state: circle with H. Their names appear below.
• State: rounded «state» box; behaviors as rows entry / name, do / name, exit / name.
• Composite state: a state containing substates (decomposed by), drawn as a container, to Levels deep (default 3).
• Parallel state: «parallel state» container with stacked «region» compartments (dashed).
• Transitions: open arrows labelled name [guard] / effect. States are ordered along the transitions: initial first, final last.
• Transitions stored as plain Actions (older models) are orange and labelled Legacy transition (Action).

Palette

New: Initial State, Final State, History State, State, Parallel State (created with two regions), Region (onto a parallel state), Entry Action, Do Action, Exit Action (onto a state). Existing: Characteristics and Actions; an existing entity gets the labels of the slot it fills.

Drop rules:

• States go onto the canvas (top level) or into a state (substate). States dropped on a parallel state must go into one of its regions.
• A region stays inside a parallel state.
• A state has at most one entry, one do and one exit behavior.

Connecting and the transition inspector

Drag from a state onto another and release over Transition. A Transition "New Transition" is created (source pushes it, it fetches the target).

For a legacy transition the panel says This transition is a plain Action (older model). with Convert to Transition.

Use Case Diagram

Use cases, the actors that perform them, and system boundaries. The root is an Action; use cases are its child Actions.

What it shows

• Use cases: ellipses for each child Action (new ones get the Use Case label).
• Actors: stick figures for every Asset that performs a use case on the diagram, plus actors you placed. Actors sit to the left or right of their use cases.
• System boundaries: grey titled rectangles. They are drawings on this diagram only, not entities.
• Lines: performs (plain line from actor to use case), «include» and «extend» (dashed, open arrow).

Palette and editing

• New: Use Case, Actor (a new Asset "New Performer"), System Boundary (200 × 400, titled System Boundary). Existing: Actions and Assets.
• Drop a use case onto an actor to make the actor perform it; drop an actor onto a use case for the same link.
• Double-click a boundary to rename it (System Boundary → Title); drag its blue bottom-right corner to resize (at least 120 × 120). Double-click a use case or actor to open its Entity View.
• Remove an actor: it leaves the diagram and loses its performs links to the use cases shown. Remove a use case: it is no longer a child of the root.

Connecting

The target splits left and right:

Anything else: Connect use cases to use cases (include/extend) or actors to use cases. Paths ▾ switches a line between «include» and «extend».

Requirement Diagram

Requirements and the elements that satisfy, verify, derive, refine, copy or trace them. The root is a Statement or Requirement (a document section works well).

What it shows

• The root and its decomposed by children to Levels (default 2), every entity linked to them by a trace relationship, and elements you placed.
• Boxes «Requirement», «Statement», «Asset», «Action», «Test Case» and so on, with requirement lines: Id = number, Text = description (up to three lines), then each requirement attribute that has a value.
• Containment: a line with ⊕ at the parent.
• Trace lines: dashed with an open arrow from client to supplier, labelled «copy», «deriveReqt», «refine», «satisfy», «verify» or «trace».

Toolbar and palette

• Attributes ▾ → Hide/Show Attributes: Id, Text, each requirement attribute, and Property Names (show or hide the Name = prefixes).
• Levels, Frame ▾, Paths ▾, Delete, Layout ▾.
• New: Requirement, Statement, Asset, Action, Test Case, Other Class… (opens Choose Class). Existing: any entity.

Drop rules: a statement onto a statement becomes its child (numbered next under it); any other element onto a requirement gets the default trace (Test Case → «verify»; Asset or Action → «satisfy»; others → «trace»); a statement dropped on empty canvas becomes a child of the root, and any other element dropped there is placed on this diagram only. Two non-requirements dropped on each other: Connect it to a requirement to keep it on the diagram.

Connecting

• Between two statements or requirements: Containment (decomposed by) or Trace (traced to).
• Between a requirement and another element: the default trace for the element, plus «trace» (traced to).
• At least one end must be a statement: One end of a requirement relationship must be a Statement or Requirement.
• Paths ▾ offers containment (two statements), copy, deriveReqt and refine (two requirements), satisfy (not between two statements), verify and trace.

Package Diagram

Packages nested by containment, with dependencies. The root is an Asset; packages are its child Assets.

• Shapes: folder-tab packages. A package with children is drawn as a container in a depth-shaded blue, to Levels deep (default 3).
• Dependencies: dashed lines with an open arrow, labelled «import» or the dependency's Context.
• Palette: Package (an Asset with the Package label). Existing: Assets.
• Nesting: drag a package into another to move it (decomposed by); onto the canvas to make it a child of the root.
• Connecting: containment (decomposed by) or import (related to).
• Paths ▾: access, apply, conform, dependencyType, import, reference (sets Context), or containment. The inspector shows Context.
• Double-click a package to open its own Package Diagram.

Class Diagram

UML classes with attributes and operations. Listed in the General category. The root is an Asset; classes are its child Assets.

• Shapes: class boxes with Attributes (name: type) and Operations (name (param types) : return) compartments.
• Lines: composition, aggregation, generalization (open triangle at the parent) and associations. An association whose ends have Origin set shows ▶, ◀ or ◀▶.
• View ▾: All Attributes, All Operations, Relationship Attributes (association end multiplicities).
• Palette: Class, Attribute, Operation, Input Parameter, Return Type. Members go onto a class (Drop onto a class); parameters onto an operation row.
• Connecting: Composition (decomposed by) or Simple Association (connected by). Paths ▾: Aggregation, Composition, Generalization (extend), Simple Association. An association's inspector shows each end's Multiplicity and Origin.
• Import Java… opens Import Java Class into Diagram. Click Upload .java… or paste the source, then Apply (Reset clears). Each class, interface or enum becomes a child Asset (description = modifiers and kind); fields become Characteristics (Units = type, Value = initializer); enum constants become Characteristics with Units enum; methods and constructors become performed Actions, with a received Input/Output per parameter and a generated "method Return Type" Input/Output (Units = type); extends becomes extended by. Result: Imported N classes, as one undo step.

Activity Diagram

The root Action's flow in SysML activity notation. It edits the same flow as the Action Diagram: a change in either shows in both, and the Simulator runs it.

What it shows

• An initial node (filled circle) and an activity final node (bullseye).
• Actions: rounded boxes with number and name; a rake symbol marks a decomposed action (click it to open the child's activity diagram).
• Fork/Join: black bars around parallel branches. A branch with a Branch Actor is labelled «actor».
• Decision/Merge: diamonds around alternative branches, with guards and probabilities.
• Loop: a merge and a decision diamond with the label [continue ×N] name.
• Flow final (⊗) for an EXIT.
• Pins and object flows: each Input/Output an action generates is an output pin on its right edge; each one it receives is an input pin on its left edge; a green line joins them, labelled with the item name.
• Swimlanes: horizontal or vertical bands named after an Asset.
• Guards: yellow note shapes with free text.

Toolbar

Palette

New: Action, Fork/Join, Decision (Or), Decision (Loop) (all onto a control-flow edge), Branch Actor (onto a Fork/Join branch edge), Guard (free note), Swimlane (drop where the lane goes). Existing: Actions (onto an edge), Assets (onto an action: it performs it; onto a branch edge: Branch Actor; elsewhere: a swimlane) and Input/Outputs (onto an action: it generates it). Layout: Layout Diagram.

Gestures

• Drag an action onto another action: a new Input/Output "I/O" that the first generates and the second receives (as a trigger).
• Drag an element onto a control-flow edge to move it there.
• Drag a swimlane by its header to move it; drag its corner to resize (at least 80 × 60). Actions whose centre lies inside a manual lane are performed by its Asset; actions moved out lose that link.
• Double-click a guard to edit its text.

Inspector

• Action or I/O: the entity panel with Open Activity, Flatten (when decomposed) and Delete….
• Decision / Merge: Decision (the question), then Guards and probabilities: a guard and a % per branch, × removes a branch, + Branch, Delete….
• Fork / Join: one row per branch, Branch n — «actor» Name with Clear Actor, × removes a branch, + Branch.
• Loop: Iterations (sets the loop to count mode).
• Swimlane or Guard: Remove.

The activity editor sets decisions by probability and loops by count only. Use the Action Diagram for resource, script and prompt decisions.

Sequence Diagram

The root Action's flow as lifelines and messages. Lifelines are the Assets that perform the actions; messages are Input/Outputs generated by an action on one lifeline and received by an action on another.

What it shows

• Lifelines: a header per performing Asset with a dashed line. Actions with no performer go on Unallocated (missing performed by Asset), last.
• Actions: activation bars on their performer's lifeline, in flow order.
• Messages: green arrows labelled with the Input/Output name.
• Fragments: par (parallel), alt (decision, with [guard p%] per branch) and loop (label ×N) frames; ⊗ EXIT for an exit.

Toolbar and palette

• + Lifeline ▾: New Asset Lifeline… or Existing Asset Lifeline….
• Add Existing Action…: pick an action, its Source Asset and an optional Target Asset; Holarch adds it to the flow, makes the source perform it, and adds a message to the target (Add a lifeline first., Choose an action.).
• Delete.
• A warning appears when an action has several performers (X has multiple performers) or an action waits for a trigger that is never generated in this flow (Infinite loop: …).
• Palette: Lifeline (Asset) and the Asset classes; dropping places the lifeline at that position (Lifelines are Assets.). Layout: Reset Lifeline Order.

Gestures

• Drag from one lifeline to another to add a message: enter the Input/Output name. Holarch creates a sending action "Do action N" on the source lifeline (or uses the receiving lifeline's next action), the Input/Output and the receiving action, with Trigger on: Message "Name" added.
• Drag a lifeline header sideways to reorder lifelines.
• Drag an action up or down to reorder it within its sequence.
• Double-click a header, action or message to open its Entity View.
• Delete a message: Remove from Diagram (drops the generated-by and received-by links) or Delete from Database. Remove a lifeline: Remove Lifeline; its actions in this flow lose performed by.

Keyboard shortcuts

Canvas keys (zoom, pan, search) are the same as in every diagram: see Diagrams.

Options and settings

Messages

Limits

• Board diagrams draw at most 1000 shapes; Levels goes up to 10.
• View ▾, Levels and layout are per diagram; the entities are shared by every view.
• The Activity editor sets decisions by probability and loops by count only; other decision and loop modes are edited in the Action Diagram.
• The Parametric solver finds one unknown per equation; systems that need several simultaneous unknowns must be written as definitions.
• Java import reads class structure with a pattern parser: it ignores method bodies, generics detail and annotations, and it needs a package declaration.
• System boundaries, guard notes, swimlanes and frames are diagram drawings, not entities; reports and exports include them, the Database does not.

Related pages

• Diagrams: the shared canvas, toolbar, export and annotations
• Action Diagrams: the flow that Activity and Sequence Diagrams edit
• Functional Analysis: functions to allocate to blocks
• Simulation: run the activity flow
• Other Diagrams: Asset, Physical I/O, Interface Control, Layer, IDEF0, N2 and more
• Help: Block Definition Diagram, Internal Block Diagram, Parametric Diagram, Interfaces, Conduits and ICDs, Budgets & TPMs