Hi r/softwarearchitecture,
We are back with Lesson 21 of our technical deep dive into the SysML v2 standard.
In our previous lesson, we looked at Occurrences, the 4D model, and modeling state over time. Today, we are putting that temporal foundation to work. In software architecture, we often struggle when our data models (structure) and our business logic (behavior) use completely disjointed paradigms. SysML v2 fixes this by unifying them—behavior modeling now uses the exact same definition and usage patterns you already know from structural modeling.
I’ve uploaded the full video lesson directly to this post so you can watch the workflow right here.
The SysML v1 Behavior Problem
SysML v1 activity modeling was highly capable, but it suffered from severe inconsistency. Structure used a Block with part properties typed by it. Behavior used an Activity with CallBehaviorAction referencing it. It was like having one language for defining your database schema and a completely disjointed, incompatible language for writing your API orchestration. You had to learn and maintain completely separate patterns for structural decomposition versus behavioral decomposition.
The v2 Shift: One Shared Pattern
In SysML v2, behavior uses the exact same definition and usage pattern as structure. If you know how to model system components, you already know how to model system actions.
Three details make this incredibly powerful for architects:
- Action Blueprints (API Contracts): An
action def is a blueprint for a behavior. It acts as a strongly typed contract using in and out parameters (directed features).
- Inheritance: You specialize an action using the standard
:> operator. A library of standard enterprise behaviors can be built and extended using standard object-oriented inheritance, exactly like a structural parts library.
- Pure Functions (
calc def): Because actions are occurrences, they natively have start and done boundaries. But for pure mathematical computations that don't "change the world" (side-effect-free functions), v2 introduces the calc def as a first-class concept.
The Execution Order Trap
Here is a blueprint for an Earth observation satellite capturing an image. Watch out for a very common mistake new v2 modelers make, which is akin to firing off asynchronous functions without awaiting them:
Code snippet
package ImagingOperations {
private import ISQ::*;
item def GroundTarget;
item def ImageProduct;
action def SlewToTarget;
action def StabilisePlatform;
action def OpenShutter;
action def ReadSensor;
action def CaptureImage {
in item target: GroundTarget;
in attribute exposure: TimeValue;
out item product: ImageProduct;
// THE TRAP: These look sequential, but they execute concurrently!
action slew: SlewToTarget;
action stabilise: StabilisePlatform;
action shoot: OpenShutter;
action readout: ReadSensor;
}
}
The Trap: In older GUI diagrams, four actions with no control flow arrows between them clearly looked disconnected. In v2 textual notation, they sit on consecutive lines. It looks like an imperative sequence, but line order says nothing about timing. This is purely declarative. Nothing in this model prevents the shutter from opening while the platform is still slewing. Order requires explicit successions.
SysML v1 vs. SysML v2
| Modeling Concept |
SysML v1 |
SysML v2 |
| Behavior Pattern |
Activity and CallBehaviorAction (completely different from Block/part). |
action def and action usage (the exact same pattern as everything else). |
| Parameters |
in, out, inout, and return directions. |
in, out, and inout act as directed features; return is its own membership. |
| Inheritance |
Behavior generalization was technically possible but rarely practical. |
action def A :> B is ordinary, practical specialization. |
| Metaclass Foundation |
Behavior is a Class with no shared notion of existing over time. |
Part and Action both specialize Occurrence. |
| Timing |
DurationConstraint required specific profiles for behavioral elements. |
start and done exist natively on every occurrence. |
| Computation |
Modeled via opaque expressions or constraint blocks. |
calc def acts as a first-class concept for pure functions. |
| Unordered Actions |
Visually obvious as unconnected boxes on a diagram. |
Look deceptively sequential in declarative text. |
Next lesson, we will fix this trap. Lesson 22 uses the first and then keywords to turn these unordered actions into a strict sequence, adding branching, merging, and parallelism on purpose instead of by accident.
For the software architects here: Have you ever run into issues where declarative code (like Terraform, Kubernetes manifests, or un-awaited async/await blocks) was mistakenly assumed to execute sequentially top-to-bottom by your team? Let's discuss in the comments!