Model-Based Systems Engineering
SysML v2, modeling practice, simulation and verification — explained by a practicing systems engineer who models missiles, satellites and ground vehicles for a living, and teaches it on YouTube to 3,500 subscribers.
A use case tells you whether a step happened. Constraints are how you say how well it was performed — and there are four places a constraint can read from, only one of which needs an output parameter.
A derived state machine arrives already colored by route — green, blue and red. Only one thing in the source model was ever annotated. Here is how the other two colors are computed, and why the stamps that carry them are deliberately not semantic metadata.
How fast, how safe, how protected — none of it comes out of a behavioral model, and it shouldn't. Here is the vocabulary for writing those constraints so they are worth having.
A keyword that implies a type relationship turns your architecture model into something you can also reason over — cross-cutting classifications that inherit, and queries you could not otherwise write.
In SysML v1, an action had to be typed by a behavior and a part property had to
SysML v2 is here, and it changes what a "model" means. In this video I build a complete delivery drone model from scratch in about 40 lines of SysML v2 text, including a mass rollup, a requirement that checks itself, and a live failure the model catches before any engineer did. Then I show the model in a Git pull request and explain the standard API that lets your whole toolchain talk to it.
Two constraints on the same pump. Both about the same subject. Only one is an obligation.