Module 6: Cases

SysML v2 cases are specialised behaviours. Every case definition ultimately inherits from KerML’s CaseDefinition, which itself specialises Behavior from the Occurrence layer. Cases add structured semantics — actors, subjects, objectives — on top of the general behavioural machinery covered in Module 4.

KerML origin: use case def → UseCaseDefinition specialising CaseDefinition → Behavior

A use case describes a sequence of actions that a system performs to deliver a result of value to an actor. In SysML v2, use cases are first-class behaviours: they have sub-actions, parameters, and control flow, just like the actions in Module 4. The difference is that a use case adds the concept of an objective — a requirement that describes what the use case is meant to achieve.

Defining a use case

The use case def keyword declares a reusable use case template. The body contains actions that describe the scenario flow:

1
use case def DriveToDestination {
2
    doc /* The driver requests a route and the vehicle
3
         navigates autonomously to the destination. */
4

5
    objective {
6
        doc /* Vehicle arrives at the requested destination
7
             safely and within the estimated time. */
8
    }
9

10
    action enterDestination;     // step 1
11
    action computeRoute;         // step 2
12
    action navigateRoute;        // step 3
13
    action arriveAtDestination;  // step 4
14

15
    first enterDestination then computeRoute;
16
    first computeRoute then navigateRoute;
17
    first navigateRoute then arriveAtDestination;
18
}

Use case usages

A use case usage instantiates a use case definition in a specific context, binding it to a particular system or package:

1
package AutonomousVehicleUseCases {
2
    use case driveCommute : DriveToDestination {
3
        doc /* Daily commute scenario with familiar route. */
4
    }
5

6
    use case driveEmergency : DriveToDestination {
7
        doc /* Emergency routing to nearest hospital. */
8
    }
9
}

KerML origin: actor → PartDefinition with ActorMembership;  subject → SubjectMembership

Every case has a subject — the system or component being described — and one or more actors — external entities that interact with the subject. The subject keyword declares a part that the case is about; the actor keyword declares parts that participate from outside.

Declaring actors and subjects

1
part def Driver;       // external human actor
2
part def CloudService; // external system actor
3
part def Vehicle;      // the system under design
4

5
use case def DriveToDestination {
6
    subject vehicle : Vehicle;      // the system being described
7
    actor driver : Driver;          // human interacting with the vehicle
8
    actor cloud  : CloudService;    // external service providing maps
9

10
    objective {
11
        doc /* Vehicle arrives safely at destination. */
12
    }
13

14
    action driver.enterDestination;  // actor initiates the flow
15
    action cloud.computeRoute;       // actor provides route data
16
    action vehicle.navigate;         // subject performs navigation
17
}

Actors as part definitions

Actors are not a special kind of element — they are ordinary PartDefinition instances that happen to be referenced via ActorMembership. This means actors can have their own attributes, ports, and behaviours:

1
part def Driver {
2
    attribute name : String;
3
    attribute licenseLevel : LicenseType;
4
    port driverInterface : DriverHMI;
5
}

KerML origin: include use case → IncludeUseCaseUsage (a PerformActionUsage)

Use cases can be composed by including other use cases as sub-steps. The include use case statement invokes a use case definition within the body of another, similar to how perform action invokes an action definition.

Composing use cases

1
use case def Authenticate {
2
    subject vehicle : Vehicle;
3
    actor driver : Driver;
4

5
    action scanBiometrics;
6
    action validateIdentity;
7
    first scanBiometrics then validateIdentity;
8
}
9

10
use case def DriveToDestination {
11
    subject vehicle : Vehicle;
12
    actor driver : Driver;
13

14
    // Include authentication as a prerequisite step
15
    include use case auth : Authenticate;
16

17
    action computeRoute;
18
    action navigateRoute;
19

20
    first auth then computeRoute;
21
    first computeRoute then navigateRoute;
22
}

Specialising use cases

Use case definitions can specialise other use case definitions using specializes, inheriting all actors, subjects, and steps while adding or overriding specifics:

1
use case def DriveInBadWeather specializes DriveToDestination {
2
    doc /* Extends base driving use case with weather-specific
3
         precautions: reduced speed limits and sensor recalibration. */
4

5
    action recalibrateSensors;  // additional step
6
    first auth then recalibrateSensors;
7
    first recalibrateSensors then computeRoute;
8
}

KerML origin: analysis case def → AnalysisCaseDefinition specialising CaseDefinition

An analysis case is a case designed to evaluate alternatives and compute results. Unlike a use case (which describes a scenario), an analysis case produces a return value — the result of the analytical evaluation. Analysis cases are the foundation for trade studies in Module 7.

Defining an analysis case

1
analysis case def EvaluateSensorConfig {
2
    subject vehicle : Vehicle;
3

4
    objective {
5
        doc /* Determine which sensor configuration provides
6
             the best detection range at acceptable cost. */
7
    }
8

9
    in attribute sensorOptions : SensorConfig[1..*];
10
    in attribute costLimit : Real;
11

12
    // The return attribute holds the analysis result
13
    return attribute bestConfig : SensorConfig;
14
}

Analysis case with evaluation logic

The body of an analysis case can contain actions that perform calculations, filter alternatives, and produce the return value:

1
analysis case def CompareBrakingSystems {
2
    subject vehicle : Vehicle;
3

4
    objective {
5
        doc /* Select braking system with shortest stopping
6
             distance under standard test conditions. */
7
    }
8

9
    in attribute candidates : BrakingSystem[1..*];
10
    return attribute selectedBrake : BrakingSystem;
11

12
    action computeStoppingDistance {
13
        in attribute brake : BrakingSystem;
14
        out attribute distance : ISQ::LengthValue;
15
    }
16

17
    action rankCandidates {
18
        in attribute results : ISQ::LengthValue[1..*];
19
        out attribute winner : BrakingSystem;
20
    }
21
}

KerML origin: verification case def → VerificationCaseDefinition specialising CaseDefinition

A verification case describes a procedure that checks whether a system satisfies a specific requirement. It links the behavioural world (test procedures, simulations) to the requirement world (Module 5) through the verify requirement statement.

Defining a verification case

1
requirement def BrakingDistanceReq {
2
    doc /* The vehicle shall stop within 40 metres
3
         from 100 km/h on dry pavement. */
4
    subject vehicle : Vehicle;
5
    require constraint {
6
        vehicle.stoppingDistance <= 40 [m]
7
    }
8
}
9

10
verification case def VerifyBrakingDistance {
11
    subject vehicle : Vehicle;
12

13
    objective {
14
        verify requirement brakingReq : BrakingDistanceReq;
15
    }
16

17
    action accelerateTo100;
18
    action applyFullBrake;
19
    action measureDistance;
20

21
    first accelerateTo100 then applyFullBrake;
22
    first applyFullBrake then measureDistance;
23
}

The verify requirement statement

The verify requirement statement inside a verification case’s objective creates a formal link between the verification procedure and the requirement being tested. This is the SysML v2 mechanism for traceability from V&V activities back to requirements:

1
requirement def MaxLatencyReq {
2
    subject sys : AutonomousSystem;
3
    require constraint { sys.responseTime <= 100 [ms] }
4
}
5

6
verification case def VerifyLatency {
7
    subject sys : AutonomousSystem;
8

9
    objective {
10
        verify requirement latencyReq : MaxLatencyReq;
11
    }
12

13
    action injectStimulus;
14
    action measureResponse;
15
    action compareToThreshold;
16

17
    first injectStimulus then measureResponse;
18
    first measureResponse then compareToThreshold;
19
}

The following model integrates all three case types for an autonomous vehicle system: use cases for driving scenarios, an analysis case for sensor evaluation, and a verification case for braking compliance.

1
package AutonomousVehicleCases {
2
    private import ISQ::*;
3
    private import SI::*;
4
    private import ScalarValues::*;
5

6
    // ── Part definitions ─────────────────────────────────────
7
    part def Vehicle {
8
        attribute stoppingDistance : ISQ::LengthValue;
9
        attribute responseTime : ISQ::TimeValue;
10
        part sensorSuite : SensorSuite;
11
        part brakingSystem : BrakingSystem;
12
    }
13

14
    part def Driver;
15
    part def TrafficAuthority;
16
    part def SensorSuite {
17
        attribute detectionRange : ISQ::LengthValue;
18
        attribute cost : Real;
19
    }
20
    part def BrakingSystem {
21
        attribute maxDeceleration : ISQ::AccelerationValue;
22
    }
23
    part def SensorConfig {
24
        attribute lidarCount : Integer;
25
        attribute cameraCount : Integer;
26
        attribute totalCost : Real;
27
        attribute effectiveRange : ISQ::LengthValue;
28
    }
29

30
    // ── Requirements ─────────────────────────────────────────
31
    requirement def BrakingDistanceReq {
32
        doc /* Vehicle shall stop within 40 m from 100 km/h
33
             on dry pavement. */
34
        subject vehicle : Vehicle;
35
        require constraint {
36
            vehicle.stoppingDistance <= 40 [m]
37
        }
38
    }
39

40
    requirement def SensorRangeReq {
41
        doc /* Sensor suite shall detect obstacles at 200 m. */
42
        subject vehicle : Vehicle;
43
        require constraint {
44
            vehicle.sensorSuite.detectionRange >= 200 [m]
45
        }
46
    }
47

48
    // ── Use Case: Drive to Destination ───────────────────────
49
    use case def DriveToDestination {
50
        subject vehicle : Vehicle;
51
        actor driver : Driver;
52
        actor traffic : TrafficAuthority;
53

54
        objective {
55
            doc /* Vehicle arrives at destination safely
56
                 and within estimated time. */
57
        }
58

59
        action enterDestination;
60
        action planRoute;
61
        action engageAutopilot;
62
        action monitorTraffic;
63
        action arriveAtDestination;
64

65
        first enterDestination then planRoute;
66
        first planRoute then engageAutopilot;
67
        first engageAutopilot then monitorTraffic;
68
        first monitorTraffic then arriveAtDestination;
69
    }
70

71
    // ── Use Case: Emergency Stop ─────────────────────────────
72
    use case def EmergencyStop {
73
        subject vehicle : Vehicle;
74
        actor driver : Driver;
75

76
        objective {
77
            doc /* Vehicle comes to a complete stop as
78
                 quickly as safely possible. */
79
        }
80

81
        action detectObstacle;
82
        action activateEmergencyBrake;
83
        action notifyDriver;
84
        action recordIncident;
85

86
        first detectObstacle then activateEmergencyBrake;
87
        first activateEmergencyBrake then notifyDriver;
88
        first notifyDriver then recordIncident;
89
    }
90

91
    // ── Analysis Case: Evaluate Sensor Configurations ────────
92
    analysis case def EvaluateSensorConfig {
93
        subject vehicle : Vehicle;
94

95
        objective {
96
            doc /* Determine the sensor configuration that
97
                 maximises detection range within budget. */
98
        }
99

100
        in attribute configs : SensorConfig[1..*];
101
        in attribute budget  : Real;
102
        return attribute bestConfig : SensorConfig;
103

104
        action filterByBudget {
105
            in attribute allConfigs : SensorConfig[1..*];
106
            in attribute maxCost : Real;
107
            out attribute affordable : SensorConfig[1..*];
108
        }
109

110
        action rankByRange {
111
            in attribute candidates : SensorConfig[1..*];
112
            out attribute ranked : SensorConfig;
113
        }
114

115
        flow filterByBudget.affordable to rankByRange.candidates;
116
        first filterByBudget then rankByRange;
117
    }
118

119
    // ── Verification Case: Braking Distance ──────────────────
120
    verification case def VerifyBrakingDistance {
121
        subject vehicle : Vehicle;
122

123
        objective {
124
            verify requirement : BrakingDistanceReq;
125
        }
126

127
        action accelerateTo100 {
128
            doc /* Bring vehicle to 100 km/h on dry test track. */
129
        }
130

131
        action applyFullBrake {
132
            doc /* Apply maximum braking force. */
133
        }
134

135
        action measureStoppingDistance {
136
            out attribute measuredDistance : ISQ::LengthValue;
137
        }
138

139
        action evaluateResult {
140
            in attribute distance : ISQ::LengthValue;
141
            doc /* Compare measured distance against 40 m limit. */
142
        }
143

144
        flow measureStoppingDistance.measuredDistance
145
            to evaluateResult.distance;
146

147
        first accelerateTo100 then applyFullBrake;
148
        first applyFullBrake then measureStoppingDistance;
149
        first measureStoppingDistance then evaluateResult;
150
    }
151

152
    // ── Verification Case: Sensor Range ──────────────────────
153
    verification case def VerifySensorRange {
154
        subject vehicle : Vehicle;
155

156
        objective {
157
            verify requirement : SensorRangeReq;
158
        }
159

160
        action placeTargetAt200m;
161
        action runDetectionSweep;
162
        action confirmDetection;
163

164
        first placeTargetAt200m then runDetectionSweep;
165
        first runDetectionSweep then confirmDetection;
166
    }
167
}

This model demonstrates: use case definitions with actors, subjects, and objectives for driving scenarios; an analysis case with input parameters, return value, and evaluation actions for sensor selection; and verification cases with verify requirement linking test procedures to formal requirements. All three case types share the same CaseDefinition ancestry and use actions with successions to describe their procedural flow.