Appendix A: Syntax Quick Reference

This appendix is a compact index of SysML v2 syntax forms. For each construct family you will find the canonical declaration pattern, a one-line description of purpose, and a pointer to the chapter that explains the semantics in full. Use it as a quick lookup when you know what you want to write but cannot remember the exact keyword order.

Each code block is a minimal but valid syntax template. Angle-bracket placeholders like <Name> are things you supply. Items in [...] are optional. Items separated by | are alternatives.

Operators and Relationship Punctuation

Every relationship in SysML v2 is written as a punctuation token after a name. This table covers all the tokens you will encounter in declarations.

The long forms are the SysML spellings. KerML spells : as typed by and has a general conjugates keyword on type declarations; neither is a SysML keyword. Appendix G lists the full symbol/keyword pairs with the metamodel class each one creates.

Examples

// Typing: the feature waterTemp is of type Real
attribute waterTemp : Real;

// Subsetting: grinder subsets parts (narrows the inherited feature)
part grinder : Grinder :> parts;

// Redefining: espressoBrewTemp narrows and renames waterTemp
attribute espressoBrewTemp :>> waterTemp;

// Reference-subsetting: a non-owning reference to the primary sensor
ref primarySensor ::> sensors;

// Conjugation: ~WaterPort flips the direction of all port features
port def WaterPort;    // conjugate is ~WaterPort, generated automatically

// Fixed value
attribute maxTemp : Real = 96.0;

// Initial value (may change)
attribute currentTemp : Real := 20.0;

// Default value (overridable)
attribute targetTemp : Real default = 93.0;

Multiplicity

Multiplicity constrains how many instances of a feature may exist. Write it in brackets after the feature name (or after its type).

// Two sensors, exactly
part sensors : CupSensor [2];

// Optional steam wand
part steamWand : SteamWand [0..1];

// Any number of logged events
item events : LogEvent [*];

Feature Modifiers

These keywords add properties to a feature declaration. Most are prefixes that appear before the feature keyword; ordered and nonunique are the exception – they follow the multiplicity.

// Abstract part: every concrete machine must specialize this
abstract part def Machine;

// Input parameter
in attribute targetPressure : Real;

// Derived attribute computed from sub-parts
derived attribute totalMass : Real;

// Ordered list of brew steps (`ordered` follows the multiplicity)
ref action brewSteps : BrewStep [*] ordered;

Visibility

Visibility controls whether a member is accessible outside its owning namespace.

package CoffeeMachineDomain {
    public part def CoffeeMachine { ... }    // visible outside
    private part def InternalBoard { ... }   // hidden from importers
}

Documentation and Comments

// Line note -- discarded by the parser

//* Block note, also discarded.
    It runs to the closing marker, so always close it. */

/* A bare block comment IS model data: it becomes a Comment element
   whose body is this text */

doc /* Documentation attached to the owning element as model data */

comment about CoffeeMachine
    /* Standalone annotating comment -- can target any element */

// and //* are hidden terminals (hidden(WS, ML_NOTE, SL_NOTE)) – the parser throws them away, so nothing downstream can see them. /* ... */ is not hidden: alone it becomes a Comment element, and after doc it becomes documentation on the owning element.

Mind the closing marker: ML_NOTE is defined as '//*' -> '*/', so a //* note runs until the next */ anywhere later in the file. Leave one unclosed and it silently swallows everything up to the next block comment. Appendix H covers doc versus //* and when to reach for each.

Group 1: Packages and Namespaces

Packages organize model elements into named scopes.

// Plain package
package <Name> {
    <members>
}

// Library package (marks reusable standard content)
library package <Name> {
    <members>
}

// Standard library package (normative standard libraries only)
standard library package <Name> {
    <members>
}

Grammar: SysML.xtext lines 183-208

See: Chapter 4: Packages and Imports

Group 2: Imports and Aliases

Imports bring names from other namespaces into scope.

// Import a single named member
import <Package>::<Name>;

// Import all public members of a package
import <Package>::*;

// Import all members recursively (including nested packages)
import <Package>::*::**;

// Private import (imported names stay private to this namespace)
private import <Package>::*;

// Alias: give a new local name to an existing element
alias <LocalName> for <Package>::<OriginalName>;

Grammar: SysML.xtext lines 234-298

See: Chapter 4: Packages and Imports

Group 3: Definitions and Usages

Every major element kind has a paired definition (reusable type) and usage (instance within a context). The pattern is uniform across all element families.

// General pattern
<keyword> def <Name> [specialization] {
    <members>
}

<keyword> <name> [: <Type>] [specialization] [= <value>];
<keyword> <name> [: <Type>] [specialization] {
    <members>
}

The definition declares a reusable classifier. The usage declares an occurrence of that classifier within an owning definition.

Grammar: SysML.xtext lines 303-330; KerML.xtext lines 460-558

See: Chapter 3: Definitions and Usages

Group 4: Typing and Specialization

These four relationships control how types relate to each other.

// Typing (feature conforms to a classifier)
part grinder : Grinder;

// Specialization (subtype extends a supertype)
part def EspressoMachine :> CoffeeMachine { ... }

// Subsetting (a feature narrows an inherited feature)
part grinder : Grinder :> components;

// Redefinition (override an inherited feature with a new name or type)
part espressoGrinder :>> grinder;

// Conjugation (type a port by the conjugate of a port definition)
port waterReturn : ~WaterPort;

Grammar: KerML.xtext lines 332-626

See: Chapter 12: Specialization and Redefinition

Group 5: Structural Constructs

Attribute

Holds a data value (scalar, string, quantity, etc.).

// Definition
attribute def <Name> [: <SuperType>] { <members> }

// Usage
attribute <name> : <Type> [multiplicity] [= <value>];

attribute def Temperature :> Real;
attribute waterTemp : Temperature = 93.0;

Grammar: SysML.xtext lines 739-749

Enumeration

A type whose values are a fixed set of named literals.

enum def <Name> {
    <literal>;
    <literal>;
}

enum def DrinkSize {
    small;
    medium;
    large;
}

Grammar: SysML.xtext lines 764-787

Item

A thing that can flow through the system (material, energy, signal, data).

// Definition
item def <Name> [: <SuperType>] { <members> }

// Usage
item <name> : <Type> [multiplicity];

item def Water;
item def BrewedCoffee;
item waterSupply : Water [1];

Grammar: SysML.xtext lines 910-916

See: Chapter 5: Structure

Part

A physical or logical component that composes a system.

// Definition
part def <Name> [:> <SuperType>] { <members> }

// Usage
part <name> : <Type> [multiplicity];

part def CoffeeMachine {
    part grinder : Grinder [1];
    part brewer  : Brewer  [1];
}
part myCoffeeMachine : CoffeeMachine;

Grammar: SysML.xtext lines 932-938

See: Chapter 5: Structure

Port

An interaction point through which a part communicates with its environment.

// Definition
port def <Name> { <port features> }

// Usage
port <name> : <PortType>;
port <name> : ~<PortType>;    // conjugated: reverses in/out

port def WaterPort {
    out item waterOut : Water;
}
part def WaterTank {
    port waterOut : WaterPort;
}
part def Brewer {
    port waterInlet : ~WaterPort;    // conjugated: receives water
}

Grammar: SysML.xtext lines 952-985

See: Chapter 5: Structure

Connection

A link between two or more parts or port ends.

// Definition
connection def <Name> [:> <SuperType>] { <members> }

// Usage: named connection
connection <name> connect <source> to <target>;

// Usage: anonymous inline connection
connect <source> to <target>;

// Binding connector (equates two features)
bind <feature1> = <feature2>;

connection def WaterLine :> BinaryConnection;

connect waterTank.waterOut to brewer.waterInlet;

bind brewer.targetTemp = controlPanel.setTemp;

Grammar: SysML.xtext lines 1015-1080

See: Chapter 6: Connections and Interfaces

Interface

A typed connection between ports, specifying a protocol.

// Definition
interface def <Name> {
    end <portName> : <PortType>;
    end <portName> : <PortType>;
}

// Usage
interface <name> : <InterfaceType> connect <port1> to <port2>;
interface <name> connect <port1> to <port2>;        // untyped

interface def WaterInterface {
    end supply : WaterPort;
    end demand : ~WaterPort;
}
interface waterLine : WaterInterface connect
    waterTank.waterOut to brewer.waterInlet;

Grammar: SysML.xtext lines 1102-1181

See: Chapter 6: Connections and Interfaces

Allocation

A directed mapping from one element to another (logical-to-physical, function-to-component).

// Definition
allocation def <Name> [:> <SuperType>];

// Usage
allocate <source> to <target>;
allocation <name> allocate <source> to <target>;

allocate brewCycle to brewer;
allocation heatingAlloc allocate heatAction to brewer.heatingElement;

Grammar: SysML.xtext lines 1195-1216

See: Chapter 6: Connections and Interfaces

Group 6: Behavioral Constructs

Action

A unit of behavior with inputs, outputs, and internal control flow.

// Definition
action def <Name> {
    in <param> : <Type>;
    out <result> : <Type>;
    <action body>
}

// Usage
action <name> : <ActionType>;

// Perform (reference an action that already exists elsewhere)
perform action <name> : <ActionType>;

// Succession (ordering between two steps)
first <actionName>
then <nextAction>;

action def BrewCycle {
    in beanType : BeanType;
    out coffee : BrewedCoffee;
    action grind : GrindBeans;
    action heat  : HeatWater;
    action extract : Extract;
    first grind then heat;
    first heat then extract;
}
action brewCycle : BrewCycle;

Grammar: SysML.xtext lines 1352-1518

See: Chapter 7: Actions

Action Nodes (Control Flow)

Built-in action node types for structured control flow inside an action body.

// Conditional
if <condition> {
    <true branch>
} else {
    <false branch>
}

// While loop
while <condition> {
    <body>
}

// Loop-until variant (`loop` takes no condition of its own)
loop {
    <body>
} until <condition>;

// For loop
for <var> : <Type> in <collection> {
    <body>
}

// Send a message (`to` names the receiver, `via` the sending port; both optional)
send <payloadExpr> to <receiver>;
send <payloadExpr> via <senderPort>;
send <payloadExpr> via <senderPort> to <receiver>;

// Accept a message or trigger
accept <payload> : <Type>;
accept <payload> : <Type> via <port>;
accept at <time>;
accept after <duration>;
accept when <change-condition>;

// Assignment
assign <target> := <expr>;

// Control nodes (name optional)
fork <name>;              // split into concurrent branches
join <name>;              // wait for all branches
merge <name>;             // accept whichever branch arrived

// A decision node is followed by its branches, one succession per line
decide <name>;
    if <guardExpr> then <targetStep>;
    else <targetStep>;

// Abort the enclosing action
terminate;

Grammar: SysML.xtext lines 1437-1734

See: Chapter 7: Actions

State

A named state in a state machine; may contain entry, do, and exit sub-actions.

// Definition
state def <Name> {
    entry;                              // or: entry <action>;
    do;                                 // or: do <action>;
    exit;                               // or: exit <action>;
    transition <Name> first <state>
        accept <trigger>
        if <guard>
        do <effect>
        then <target>;
}

// Usage
state <name> : <StateType>;

// Exhibit (reference a state that exists elsewhere)
exhibit state <name> : <StateType>;
exhibit state <name> { <states and transitions> }
exhibit <stateUsageRef>;

// Parallel states
state <name> parallel {
    <region1>;
    <region2>;
}

state def MachineStates {
    state idle;
    state brewing;
    state cleaning;

    transition T1 first idle
        accept StartBrewEvent
        if cupDetected
        then brewing;

    transition T2 first brewing
        accept BrewCompleteEvent
        then idle;
}
state machineStates : MachineStates;

Grammar: SysML.xtext lines 1735-1923

See: Chapter 8: States

Transition

A directed arc between two states, with optional trigger, guard, and effect.

transition [<Name>] first <source>
    [accept <trigger> [via <port>]]
    [if <guard-expression>]
    [do <effect-action>]
    then <target>;

transition T1 first idle
    accept StartBrewEvent
    if cupSensor.cupDetected
    then brewing;

Grammar: SysML.xtext lines 1849-1877

See: Chapter 8: States

Succession

Ordering relationship between two occurrences (temporal “happens before”).

// Inline within an action or state body
first <occurrence1>
then <occurrence2>;

// Explicit succession
succession <name> first <occurrence1> then <occurrence2>;

// Guarded target -- follows a decision node, one line per branch
if <guardExpr> then <targetStep>;

// Default target -- taken when no guard matched (note: no `then`)
else <targetStep>;

Grammar: SysML.xtext lines 1028-1033

See: Chapter 7: Actions

Flow

A directed transfer of items between feature ends.

// Definition
flow def <Name> [:> <SuperType>];

// Usage: anonymous inline flow
flow of <ItemType> from <source> to <target>;

// Named flow usage
flow <name> of <ItemType> from <source> to <target>;

// Succession flow (ordered flow across a time boundary)
succession flow of <ItemType> from <source> to <target>;

flow def WaterFlow;
flow of Water from waterTank.waterOut to brewer.waterInlet;

Grammar: SysML.xtext lines 1230-1285

See: Chapter 6: Connections and Interfaces

Calculation

A function-like behavior that returns a value. Used for expressions and analyses.

// Definition
calc def <Name> {
    in <param> : <Type>;
    return <result> : <ReturnType>;
    <result expression>
}

// Usage
calc <name> : <CalcType>;

calc def BrewTime {
    in volume : Real;
    in pressure : Real;
    return t : Real = volume / pressure * 60.0;
}

Grammar: SysML.xtext lines 1937-1974

See: Chapter 9: Expressions and Constraints

Group 7: Analytical Constructs

Constraint

A Boolean predicate that must hold for the model to be valid.

// Definition
constraint def <Name> {
    <boolean expression>
}

// Usage
constraint <name> : <ConstraintType>;

// Inline constraint
constraint { <boolean expression> }

// Assert a constraint holds
assert constraint <name>;

// Assert a constraint does not hold
assert not constraint <name>;

constraint def BrewTempInRange {
    brewer.waterTemp >= 90.0 and brewer.waterTemp <= 96.0
}
assert constraint BrewTempInRange;

Grammar: SysML.xtext lines 1988-2012

See: Chapter 9: Expressions and Constraints

Concern

A stakeholder interest modeled as a requirement-like predicate.

// Definition
concern def <Name> { <requirement body> }

// Usage
concern <name> : <ConcernType>;

Grammar: SysML.xtext lines 2150-2160

See: Chapter 10: Requirements and Verification

Group 8: Requirements

Requirements capture what a system must do or be.

Requirement

// Definition
requirement def <Name> {
    subject <subjectName> : <SubjectType>;
    assume constraint { <assumption expression> }
    require constraint { <requirement expression> }
    frame <concern>;
    stakeholder <name>;
}

// Usage
requirement <name> : <RequirementType>;

requirement def BrewTimeRequirement {
    subject machine : CoffeeMachine;
    require constraint { machine.brewTime <= 60.0 }
}
requirement brewTime : BrewTimeRequirement;

Grammar: SysML.xtext lines 2026-2110

See: Chapter 10: Requirements and Verification

Satisfy

Declares that a subject satisfies a requirement.

// Reference an existing requirement usage
satisfy <requirementUsageRef> by <subject>;

// Declare the satisfied requirement here, typed by a requirement definition
satisfy requirement [<name>] : <RequirementDef> by <subject>;

assert satisfy <requirementUsageRef> by <subject>;
assert not satisfy <requirementUsageRef> by <subject>;

satisfy requirement : BrewTimeReq by myCoffeeMachine;

Grammar: SysML.xtext lines 2112-2120

See: Chapter 10: Requirements and Verification

Group 9: Cases

Cases are structured analyses with a subject, objective, and result.

Analysis Case

Captures a system analysis (e.g., performance, safety).

analysis def <Name> {
    subject <name> : <SubjectType>;
    objective { <requirement body> }
    <action body items>
    return <result> : <ResultType>;
}
analysis <name> : <AnalysisType>;

Grammar: SysML.xtext lines 2227-2233

See: Chapter 10: Requirements and Verification

Verification Case

Documents how a requirement is verified.

verification def <Name> {
    subject <name> : <SubjectType>;
    objective { verify requirement <ReqName>; }
}
verification <name> : <VerificationType>;

Grammar: SysML.xtext lines 2249-2255

See: Chapter 10: Requirements and Verification

Use Case

Documents system usage by actors.

use case def <Name> {
    subject <name> : <SubjectType>;
    actor <actorName> : <ActorType>;
    objective { <requirement body> }
}
use case <name> : <UseCaseType>;

// Include another use case inline
include use case <name>;

Grammar: SysML.xtext lines 2287-2301

See: Chapter 10: Requirements and Verification

Group 10: Views and Viewpoints

Views select and frame content for a specific audience.

Viewpoint

Defines the concerns and stakeholders a view must address.

viewpoint def <Name> {
    stakeholder <name> : <StakeholderType>;
    frame <concern>;
    require constraint { <criteria> }
}
viewpoint <name> : <ViewpointType>;

Grammar: SysML.xtext lines 2399-2405

See: Chapter 13: Metadata and Views

View

Projects selected model content through a rendering.

view def <Name> :> <SupertypeView> {
    filter <BooleanExpression>;
    render rendering <name> : <RenderingDef>;
}

view <name> : <ViewType> {
    expose <element>;                  // member expose
    expose <Namespace>::*;             // namespace expose
    filter <BooleanExpression>;
    render <renderingUsageRef>;
}

// Anonymous view usage — no def required
view <name> { expose <element>; }

view def StructuralView :> InterconnectionView {
    filter @SysML::PartUsage;
    render rendering asTree : Views::GraphicalRendering;
}
view structuralView : StructuralView {
    expose CoffeeMachineDomain::*;
}

view scratch { expose CoffeeMachine; }   // anonymous

expose is legal only in a view usage body; a view definition body admits filter and render (ViewDefinitionBodyItem has no expose alternative). sysml-rs currently fails to flag an expose inside a view def – do not read that as acceptance.

The eight standard view definitions (package StandardViewDefinitions) are: GeneralView, InterconnectionView, ActionFlowView, StateTransitionView, SequenceView, GeometryView, GridView, BrowserView. There is no standard UseCaseView or RequirementView; a requirement view is written as a GeneralView specialization with a requirement-metaclass filter.

filter expressions are Boolean and are evaluated once per exposed element. The spec’s own idiom is a classification test against a metaclass or metadata definition – filter @SysML::PartUsage;, filter @Safety and Safety::isMandatory;. The self, kind, name, and id bindings used elsewhere in this book are a sysml-rs evaluator extension, not spec language. Multiple filter clauses on the same view compose as logical AND.

Grammar: SysML.xtext lines 2315-2383

See: Chapter 13: Metadata and Views

Rendering

Defines how a view’s contents should be displayed.

rendering def <Name> { <rendering body> }
rendering <name> : <RenderingType>;

Grammar: SysML.xtext lines 2417-2427

Group 11: Metadata

Metadata annotates any model element with typed, queryable data.

// Definition (a metaclass)
metadata def <Name> {
    attribute <field> : <Type>;
}

// Usage: attach metadata to an element
@<MetadataType> { <field> = <value>; }

// Using the metadata keyword explicitly
metadata <name> : <MetadataType> about <element>;

// Prefix form: a user-defined keyword before the declaration it annotates
#<MetadataType>
<annotated element>

metadata def ReviewStatus {
    attribute reviewer : String;
    attribute approved : Boolean;
}

part def CoffeeMachine {
    // Without an `about` clause, a metadata usage annotates its
    // containing element -- so this attaches to CoffeeMachine
    @ReviewStatus { reviewer = "Alice"; approved = true; }
}

Grammar: SysML.xtext lines 115-177

See: Chapter 13: Metadata and Views

Group 12: Expressions

Expressions compute values. They appear in constraints, feature values, calculations, and guard conditions.

Arithmetic and Logic Operators

Type Testing and Casting

// Test whether a value is an instance of a type
<expr> hastype <Type>
<expr> istype <Type>
<expr> @ <Type>

// Cast to a type
<expr> as <Type>

// Metaclass test / cast
<expr> @@ <MetaType>
<expr> meta <MetaType>

// Extent: all instances of a type
all <Type>

Collection and Feature Navigation

// Dot notation: navigate to an owned feature
brewer.waterTemp

// Feature chaining: navigate through a chain
machine.brewer.waterTemp

// Sequence expression (parenthesized, comma-separated)
(a, b, c)

// Range (also usable in expressions)
1..10

// Indexing (1-based)
<sequence>#(n)

// Sequence operators (arrow form; the per-element rule is a body expression)
<sequence>->select {in <x>; <predicate over x>}
<sequence>->collect {in <x>; <expr over x>}
<sequence>->reject {in <x>; <predicate over x>}
<sequence>->forAll {in <x>; <predicate over x>}
<sequence>->exists {in <x>; <predicate over x>}

// Aggregators (argument-list form -- the sequence is the argument)
<sequence>->size()
<sequence>->isEmpty()
<sequence>->notEmpty()
<sequence>->sum()
<sequence>->product()

// min and max are two-argument functions, so a sequence is folded with ->reduce
<sequence>->reduce min
<sequence>->reduce max

Body Expression (Inline Function)

// Body expression -- the inline function passed to ->select, ->collect, ->forAll, ...
{in <param>; <expression>}
{in <param> : <Type>; <expression>}

Grammar: KerMLExpressions.xtext (full file, 579 lines)

See: Chapter 9: Expressions and Constraints

Occurrence Modifiers

Occurrences (parts, items, actions, states) can carry temporal modifiers.

individual part myEspressoMachine : EspressoMachine;
snapshot part machineAtStartup : CoffeeMachine;
timeslice part machineInOperation : CoffeeMachine;

Grammar: SysML.xtext lines 801-860

The Definition/Usage Pattern (Summary)

Every major construct family in SysML v2 follows this paired pattern:

connect <a> to <b> is not the connection usage keyword – it is the clause that introduces the ends, and stands alone only as the short form of an unnamed connection. The same pattern holds for allocate (usage keyword allocation) and bind (usage keyword binding). See Appendix G for the metamodel class behind each pair.

Cross-References

• Chapter 1: Why Textual SysML v2 introduces the definition/usage split and explains why the language is text-first.
• Chapter 3: Definitions and Usages explains ownership and membership semantics.
• Chapter 4: Packages and Imports explains packages and imports in depth.
• Chapter 5: Structure explains parts, items, attributes, and ports.
• Chapter 6: Connections and Interfaces explains connections, interfaces, allocations, and flows.
• Chapter 7: Actions explains actions, action nodes, and successions.
• Chapter 8: States explains state machines and transitions.
• Chapter 9: Expressions and Constraints explains calculations, constraints, and expressions.
• Chapter 10: Requirements and Verification explains requirements, concerns, cases, and satisfaction.
• Chapter 12: Specialization and Redefinition explains every relationship operator in the table above.
• Chapter 13: Metadata and Views explains the metadata system, views, and viewpoints.

Source Anchors

• Grammar (primary): references/sysmlv2/SysML-v2-Pilot-Implementation/org.omg.sysml.xtext/src/org/omg/sysml/xtext/SysML.xtext (2,433 lines)
• Grammar (KerML base): references/sysmlv2/SysML-v2-Pilot-Implementation/org.omg.kerml.xtext/src/org/omg/kerml/xtext/KerML.xtext
• Grammar (expressions): references/sysmlv2/SysML-v2-Pilot-Implementation/org.omg.kerml.expressions.xtext/src/org/omg/kerml/expressions/xtext/KerMLExpressions.xtext
• Metamodel vocabulary: references/sysmlv2/SysML-vocab.ttl (182 SysML types)
• KerML vocabulary: references/sysmlv2/Kerml-Vocab.ttl (84 KerML types)
• Corpus examples: sysml-spec-tests/corpus/advent/ (56 files)
• Coffee Machine examples: examples/coffee-machine/ (12 files)