SYSML21 — Semantic Role of Use Cases in the SysML Metamodel

The current SysML metamodel defines use cases as specializations of behavioral elements—effectively treating them as calculations or executable functions. This characterization is semantically inconsistent with the foundational role of use cases in systems modeling. Use cases are not behaviors the system performs internally; rather, they represent contracts or agreements between external actors and the system, specifying what the system is expected to do in response to a stimulus. Modeling use cases as executable behaviors introduces a category error into the metamodel and risks conflating external interactions with internal mechanisms.
Use cases, by their very nature, are interaction scenarios. They do not define how a result is computed or executed, but instead describe what result is expected when a particular actor engages the system in a defined way. Their semantics are declarative and externally visible; they are about outcomes, not procedures. As such, the current inheritance from computational behavior types (such as Function or Behavior) is conceptually incorrect. This structural alignment misleads modelers and tool developers into treating use cases as execution artifacts, which they are not.
If the metamodel insists that use cases must derive from a parent behavioral concept, a more accurate—though still imperfect—choice would be to inherit from a construct akin to a state transition. This would at least preserve the idea that use cases mark a change in the system’s externally observable state as a result of actor interaction. Even so, this remains a second-best solution, as it still imposes a behavioral framing on what should be a scenario-based modeling construct.
The preferred and semantically coherent approach is to model use cases as a distinct first-class metamodel element, such as a Scenario. This new metaclass should stand apart from behavioral execution elements and focus solely on external intent, interaction structure, and resulting system obligations. Two clear examples of such Scenario constructs would be Use Cases and Acceptance Test Scripts. Doing so would reinforce the modeling clarity that use cases are not descriptions of how the system behaves internally, but agreements about what the system must do when engaged from the outside.
Separating use cases from procedural behavior elements also promotes stronger model validation and traceability. It enables more accurate conformance checking between actor expectations and system behavior without enforcing implementation-specific logic. This adjustment to the metamodel aligns better with the practical and pedagogical use of use cases in systems engineering and eliminates the conceptual mismatch that currently exists.
In summary, the treatment of use cases as calculations within the SysML metamodel introduces a fundamental misalignment between semantics and structure. Reframing use cases as scenario-based constructs—independent from executable behaviors—restores conceptual clarity and reinforces the integrity of the modeling language. This change would provide immediate benefit to the precision, usability, and future extensibility of SysML.