Modeling Business Systems

and Processes with SysML v2

Gerd Wagner

Brandenburg University of Technology

Germany

Slides available from sim4edu.com/reading/sysml/BIR-2025.

Overview

  1. UML and SysML
  2. Ontological Foundations of SysML v2
  3. Modeling the State Structure of a System
  4. Modeling the Dynamics of a System
  5. Modeling a Business System
  6. What about Events?

The talk is based on the book Understanding KerML and SysML v2.

The models in this presentation have been checked (and visualized) with the help of the SysML v2 tool SysIDE, for which a free community version and a free academic professional license is available.

UML and SysML

History of SysML

  • 1997: UML 1.1
  • 2005: UML 2
  • 2007: SysML v1
  • 2008: Foundational UML (fUML)
  • 2017: Unified Architecture Framework (UAF)
  • 2025: SysML v2

Issues of UML and SysML v1

  1. UML has three different, but overlapping, behavior modeling languages (state machines, activity diagrams and sequence diagrams), which are not conceptually aligned/integrated with each other.
  2. UML behavior modeling is not conceptually integrated with state structure modeling.
  3. UML does not have a precise (formal) semantics for its behavior modeling languages.
  4. Since SysML v1 simply extends UML 2, it has the same issues as UML.

SysML v2

  • ... is a domain-independent systems modeling language, which allows modeling all kinds of systems, including socio-cyber-physical systems such as information systems, spacecrafts or smart cities.

  • ... builds upon 30 years of UML and 20 years of SysML v1 and improves them by

    • defining a unified behavior modeling language based on the concepts of actions and states,
    • integrating behavioral with structural modeling,
    • providing a formal semantics, and
    • supporting further SE concepts, such as Analysis Cases, Verification Cases, Views, and Variations.

Ontological Foundations of SysML v2

Objects
Events
Actions
Processes

Objects

  • A system is modeled as a composite object, such that its parts may perform actions (and interact with each other).
  • System parts are also modeled as (possibly composite) objects.

Occurrences

In Philosophy/Ontology, it's widely acknowledged that events, actions, activities and processes are occurrences, which

  • happen over time;
  • are 4-dimensional: they extend in space and time;
  • have temporal parts.

Are Objects 3D or 4D?

In Philosophy/Ontology, there are two different views of objects:

3D Continuants
Objects extend in space, but not in time. They do not have temporal parts; rather, they are wholly present at any point in time. They do not happen, but persist over time. An object and its history are two different things.
4D Occurrences
Objects extend in space and time. They have temporal parts and only a temporal part of them is present at any point in time. They happen over time. An object and its history are the same.

3D or 4D

UMLKerML / SysML v2
actions/activities4D Occurrences4D Occurrences
objects3D Continuants4D Occurrences

Objects as Occurrences

  • Objects-as-Occurrences
    Both objects and actions are occurrences in SysML2.
  • Therefore objects have both a start and an end snapshot, and also time slices.
  • Objects may be the performers of, and involved in, actions.

Modeling the
State Structure
of a System

Items
Parts
Connections
Ports

Items and Parts

  • In SysML v2, objects are called items.
  • The parts of a system are viewed as special items.
  • A system, as a composite object, is also classified as a part since it may be a subsystem of a larger system.

Core Modeling Concepts

Types
classify things and may have features.
There are two kinds of types: classifiers and features.
Classifiers
are types that classify things.
Examples: data types, item types, action types.
Features
model the relations between things.
Examples: attributes, item properties, action steps.

Types

  • The set of things classified by a type is called its extent.
  • Each member of its extent is an instance of the type.
  • Everything is an instance of the predefined type Anything.
  • Types may have features. Consequently, not only classifiers, but also features may have features.
  • A type S may specialize another type T. Then S is a subtype of T and T is a supertype of S. A subtype inherits all features of its supertypes.

Examples of Classifiers and Features

An item type definition with two attributes
item def Person {
  attribute name : String;
  attribute age : Natural;
}
Two part type definitions
part def Engine;
part def Wheel;

A part type definition with four features
part def Car {
  attribute mass : ISQ::MassValue;
  Three part properties
  part engine : Engine;
  part wheels[4] : Wheel;
  ref part driver[0..1] : Person;
}
  1. The data type MassValue is predefined in the library package ISQ.
  2. wheels[4] means that the part property wheels has the multiplicity 4, implying that it has exactly 4 values.
  3. driver[0..1] means that this part property has at most one value.
  4. By default, part properties are "composite" features, representing parts/components, which cannot exist after the whole ceases to exist, unlike "referential" features.
  5. ref part means that this part property is not composite, but referential.

Terminology

SysML v2 comes with a superfluous jargon: calling classifiers (like data types or item types) "definitions" and calling features (like attributes or item properties) "usages", which is confusing.

Official TerminologyMy Preferred Terminology
attribute definitiondata type
attribute usageattribute
item (part/port/action/etc.) definitionitem (part/port/action/etc.) type
item (part/port/etc.) usageitem (part/port/etc.) property
action usageaction property (or action step)

Modeling the Dynamics of a System

Actions
Successions
Control Nodes
States

Actions

  • Actions may be atomic or composite, and they may have some duration or may be instantaneous.
  • In SysML v2, actions can represent both
    1. high-level behaviors, such as business activities, and
    2. low-level behaviors, such as computational actions like value assignments.
  • Remarkably, control nodes, which are used for expressing conditional and parallel branching in flow-chart modeling languages (like BPMN), represent special types of action steps in SysML v2.

Action Types and Action Steps

An action type classifies actions (or action performances). An action property ("usage") is an action-valued feature. A composite action type has action properties representing action steps.

action def Focus;
action def Shoot;
action def TakePicture {
  action focus[1] : Focus;
  action shoot[1] : Shoot;
}

The composite action type TakePicture has two action steps, focus and shoot, both of which have the multiplicity 1 expressing that a TakePicture action is composed of one focus and one shoot action.

part def Camera {
  attribute model : String;
  action focus[*] : Focus;
  action shoot[*] : Shoot;
}

The part type Camera has two action properties, focus and shoot, both of which have the multiplicity zero-or-many expressing that during the lifetime of a Camera, it may perform zero or many actions of these two types.

How to Express "Control Flow" Arrows in SysML v2?

What does a "control flow" arrow mean?

  • A causal triggering relationship?
  • An immediate succession?
  • Or just a temporal precedence?

Successions

Action steps, such as focus and shoot, can be sequenced with the help of successions, which are special properties for connecting action steps expressing temporal precedence.

action def TakePicture {
  action focus[1] : Focus;
  action shoot[1] : Shoot;
  succession [1] focus then [1] shoot;
}

In this example, the source and target of the succession, focus and shoot, have the multiplicity of 1, implying that a focus action is succeeded by exactly one shoot action and a shoot action is preceded by exactly one focus action.

Modeling a Hotel as a Business System

This example is inspired by an example presented in (Pesic et al 2007).

A Hotel with Business Units and Positions

part def Hotel1 {
  attribute name;
  attribute numberOfRooms;
  ref part director;
  part frontOffice;
  part foodAndBeverage;
  part housekeeping;
}

Nested Business Units

part def Hotel2 {
  part frontOffice {
    ref part manager;
    ref part receptionists[*];
  }
  part foodAndBeverage  {
    ref part manager;
    part kitchen {
      ref part chef;
      ref part cooks[*];
    }
    part restaurant {
      ref part waitstaff[*];
    }
  }
  part housekeeping {
    ref part manager;
    ref part housekeepers[*];
  }
}

Adding Business Actions

part def Hotel {
  ...
  action rentHotelRoom {
    action bookRoom[1];
    action checkIn[0..1];
    action provideRestaurantService[*];
    action provideLaundryService[*];
    action bill[1..*];
    action charge[1];
    action checkOut[0..1];
    first [*] provideLaundryService 
      then [1..*] bill;
    ...
}

With five action cardinality constraints:

  1. The actions bookRoom and charge are executed exactly once.
  2. The actions checkIn and checkOut are executed at most once.
  3. The action bill is executed at least once.

And one Follow-Up constraint: A laundry service must be succeeded by a bill action.

Further Dynamic Constraints

first [*] provideLaundryService 
  then [1..*] bill;
first [*] provideRestaurantService
  then [1..*] bill;
first [1..*] bookRoom
  then [*] checkIn;
first [1..*] checkIn
  then [*] provideRoomService;
first [1..*] checkIn
  then [*] provideLaundryService;
first [1..*] bookRoom
  then [1..*] charge;
first [1..*] checkIn
  then [1..*] checkOut;
  1. Two Follow-Up constraints: Both a restaurant and a laundry service must be succeeded by a bill action.
  2. Three Precedence constraints: (1) A check-in must be preceded by a book room action. (2+3) Both a restaurant and a laundry service must be preceded by a check-in.
  3. Two combined Follow-Up/Precedence constraints: (1) A book room action must be succeeded by a charge, and a charge must be preceded by a book room action. (2) A check-in must be succeeded by a check-out, and a check-out must be preceded by a check-in.

Declarative Business Process Modeling (BPM)

  • Unlike imperative BPM languages like BPMN,
  • ... declarative BPM languages like DECLARE (Pesic et al 2007) do not prescribe, but only constrain, the admissible sequences of events and actions.
  • The meaning of DECLARE constraints is defined by translating them to Linear Temporal Logic (LTL) formulas.
  • SysML v2 also allows declarative process modeling.
  • But unlike declarative BPM languages, SysML v2 integrates process modeling with information modeling.

SysML v2 and Declarative BPM

Name of constraint type SysML2 declaration pattern LTL formula Explanation of the constraint's meaning
Follow-Up first [*] focus then [1..*] shoot □( focus ⇒ ◇shoot) A focus action must be succeeded by a shoot action.
Precedence first [1..*] focus then [*] shoot (¬shoot U focus) v □(¬shoot) A shoot action must be preceded by a focus action.
Exclusion first [0] cancel then [0] charge □( cancel ⇒ ¬◇charge) A cancel (order) action must not be succeeded by a charge action, implying that a charge action must not be preceded by a cancel action.

What about Events in SysML v2?

Processes Consist of Events and Actions

  • Like in UML, also in SysML v2.0, there is no concept for modeling events.
  • But such a concept is needed for being able to model, for instance, message reception events or failure events,
  • ... and for Discrete Event Simulation.

But hopefully, in a future SysML v2.x, we can express processes like so:

process rentHotelRoom {
    event bookingRequest[1];
    action bookRoom[1];
    event customerArrival[0..1];
    action checkIn[0..1];
    ...
    first [1] bookingRequest 
      then [1] bookRoom;
    ...
}

SysML v2.0

Objects-as-Occurrences

SysML v2.x with Events

Objects-as-Occurrences

Conclusions

  • SysML v2 is a powerful language that does not only allow modeling (socio-)technical systems, but also business systems and processes in a declarative way.
  • Today, SysML v2 is the most powerful BPM language.
  • It needs to be extended by adding a concept for modeling events.
  • In future work I plan to investigate how to use SysML v2.x for Event-Based Simulation, which is the most fundamental form of Discrete Event Simulation.

The END