Systems Modeling Language (SysML)

Antonio Moschitta
Outline
• SysML origins and purpose
• SysML characteristics
 Origins and purposes
• SysML is a general-purpose visual (i.e. graphical) modeling language,
suitable for SE applications [1]
• SysML is a dialect of UML 2, and is defined as a UML 2 «profile»
• «profile»: a UML dialect that customizes the language using 3 mechanisms
• Created in 2003 by the SysML Partners' SysML Open-Source Specification
Project [2], then adopted and modified by the Object Management Group
(OMG) in 2006 [3].
• The language current version is 2 [3]
• Aims at capturing all of information about a system in one place (Single
Source of Truth)
Origin and Purposes: SysML vs UML 2

Image source: [4]

Origins and purposes: SysML vs UML 2

SysML Diagram Types

Image source: [4]

 Origins and purposes
• Aims at capturing
• Functional behavioral models
• Performance models
• Structural topology (parts and interconnections)
• Any other engineering analysis models
• In comparison with UML
• Reduces the focus on Software Engineering applications
• Focused on Cyber-physical systems
• Software-specific diagrams (e.g. deployment diagram) were removed
• In comparison with OPM
• Envisions integration with external analysis tools (moves information from
description to analysis model and the other way around)
• Incorporates requirements explicitly
 Origins and purposes
• Supports logical and physical decomposition of systems
• Supports the description of constraints
• Has no built-in simulation or analysis capabilities, but the tools that support
the language may add this feature
• Support various kinds of diagrams, that can be linked
• Diagrams and links together form the model
 Origins and purposes
• A modification to a diagram propagates to all the related diagrams…
• …because there is an underlying backend database (Single Source of Truth!)
 Applications
• Requirements Engineering: requirements are implemented as constraints on
the model, rather than being expressed as textual descriptions
• System Description: allows study of potentially more than a single mission
concept within a given timeframe (intersects with Domain Systems
Modeling)
• Integration with Analysis Tools
• External modeling tools like Matlab, Simscape, SDK, Thermal Desktop, Phoenix
ModelCenter… [OCW, 1:06:27]
• Idea: Take information out of the model, do an analysis, put the information back in
the model
 Characteristics of SysML
• SysML is object-oriented
• SysML relies on a backend database to avoid documentation, aiming at
outdoing Document Based Approaches
 Characteristics of SysML
• 9 Diagrams, divided in two main groups
• Behavior
• Activity Diagram
• Sequence Diagram
• State Machine Diagram
• Use Case Diagram
• Structure
• Block Definition diagram Image source: [4]
• Internal Block Diagram
• Parametric Diagram
• Package Diagram
• Requirement Diagram
 Characteristics of SysML
• Activity Diagram
• Represents a flow of activities, that can be tied to
systems elements
Image source: [4]
• Sequence Diagram
• Focused on logical ordering
• Example: description of interacting threads in a
multithread software system (inherited from UML)
• State Machine Diagram
• Suitable if a System has states, focused on what
triggers or causes transitions between states
• Supports the concept of guards that must be met
before transitioning between states
 Characteristics of SysML
• Use Case Diagram
• Focused on early concept development, and from
stakeholder (how they do interface to the system and
how they do derive value) Image source: [4]
• Block Definition Diagram
• Used to define the logical or physical decomposition of a
system into subsystems
• Internal Block Diagram
• Defines the ties between the components of a system,
using “interfaces”
• Parametric Diagram
• It is a sub-diagram of the Internal Block Diagram, permits
to put mathematical or logical constraints on the
interfaces
• Putting constrains is the first step to compute a model
 Characteristics of SysML
• Packaging Diagram
• Focused on the organization of the model
• Requirement Diagram Image source: [4]
• Focused on showing how the requirements are
related to the system
 Characteristics of SysML
• Blocks
• Chevrons <<>> denote stereotyping (a form of
inheritance)

Image source: [5]

 Characteristics of SysML
• Blocks
• A block description can be enriched by adding
• Properties
• Operations

• Properties are represented by names

• Operations are represented by verbs

Image source: [5]

 Characteristics of SysML
• Associations

Image source: [5]

 Characteristics of SysML
• Associations

Image source: [5]

 Characteristics of SysML
• Associations

Image source: [5]

 Characteristics of SysML
• Associations and multiplicity

Image source: [5]

 Characteristics of SysML
• Aggregation “is made of entities that exist on
their own”

Image source: [5]

 Characteristics of SysML
• Aggregation and composition

• Composition “is made of entities that do not

exist on their own”

Image source: [5]

 Characteristics of SysML
• Specialization
• “is a types of…”
• “…has subtypes”

Image source: [5]

 Characteristics of SysML
• Specialization
• Expresses inheritance

Image source: [5]

 Characteristics of SysML
• Specialization
• Expresses inheritance

Implies that…

Image source: [5]

 Characteristics of SysML
• Dependency (dashed arrow with tip)
• Changes in block B result into changes in block A
• “A depends on B”

Image source: [5]

 Characteristics of SysML
• Metamodels
• SysML and its elements can be described using the SysML conventions

Image source: [5]

 Characteristics of SysML
• Metamodels
• SysML and its elements can be described using the SysML conventions

Image source: [5]

 Characteristics of SysML
• Diagrams
• A frame is a graphic node that encapsulates the diagram

Unique

Images’ source: [5]

 Block Definition Diagram
• Abbreviation: bdd
• Relationships
• Association
• Aggregation
• Composition
• Dependency
• Generalization

Image source: [5]

Block Definition Diagram

• Standard Port: exchange of

services defined by an interface Image source: [5]
• Flow port: material, data or
energy are exchanged
Block Definition Diagram

• Standard Port: exchange of

services defined by an interface Image source: [5]
• Flow port: material, data or
energy are exchanged
Block Definition Diagram: an example

Image source: [5]

Block Definition Diagram

Image source: [5]

 Block Definition Diagram
• A provided interface accepts an input
and acts consequently
• A required interface generates an output
and sends it to the interface provided by
another part.
Image source: [5]

• Using SysML integrity and consistency can be verified (e.g.: a script can be
written that checks whether all ports are connected to something and if the
connections are consistent)
 Block Definition Diagrams
• Interfaces can be defined using bdds as well!
 Block Definition Diagrams
• Interfaces can be defined using bdds as well!
 Block Definition Diagram
• Ports define flows and their direction
• A conjugate port has a complementary Images’ source: [5]
behavior with respect to its counterpart
• Example:
 Internal Block Diagram
• Abbreviation: idb
• Partial metamodel

Image source: [5]

 Internal Block Diagram

• Abbreviation: idb

Image source: [5]

• Based on the concept of “Part”
• The internal block diagram provides emphasis on the internal structure of
a block and on the logical relationships between parts
• Interconnections are shown in terms of composition/aggregation and in
terms of flows using “Ports”
Internal Block Diagram
The ibd can also be used to partially implement “instantiation”

Images’ source: [5]

 Internal Block Diagram: an example
• Example: flight control
system
• Parts do not depend on
each other

Image source [6]

 Internal Block Diagram
• Example: flight control
system
• Parts do not depend on
each other

Image source: [6]

• Parts are connected using ports (squares)

• Ports are connected using connectors (lines with arrows)
• NB: the number of ports is approximately twice the number of interfaces,
measuring the complexity of a system
• Typical number: 5-6 ports per part [7]
 Interface Block Diagram
• A provided interface accepts an input and acts
consequently
• A required interface generates an output and sends it to the Image source: [6]

interface provided by another part.

Image source: [5]

Image source: [5]
• The previous bdd shows that a limb can be a caterpillar, a wheel or a leg
• The following ibd adds details on how the wheels transfer torque to the robot structure

Image source: [5]

• Similarly, an idb can provide further details on the implementation of the Controller software

Image source: [5]

 Package Diagram
• The package diagram relates together packages
• Packages are defined as collection of diagram elements
• The pkg relates model elements at high level

Image source: [5]

 Package Diagram
• Abbreviation: pkg
• The dependency can be defined using two stereotypes,
<<import>> (public import) and <<access>> (private
import).

Image source: [5]

 Package Diagram
• Abbreviation: pkg
• The dependency can be defined using two stereotypes,
<<import>> (public import) and <<access>> (private
import).
• In example (a) A can see C, in example (b) A cannot see C

Image source: [5]

 Package Diagram
• The package are a generic container for other SysML elements (see
metamodel below)

Image source: [5]

 Package Diagram
• Example

Image source: [5]

 Parametric Diagram
• Abbreviation: par
• The parametric diagram contains a SysML specific construct, the constraint
block
• The constraint block permits to express rules that constrain the behavior of
a system

Image source: [5]

 Parametric Diagram
• Abbreviation: par
• The parametric diagram contains a SysML specific construct, the constraint
block
• The constraint block permits to express rules that constrain the behavior of
a system

Image source: [5]

 Parametric Diagram
• Abbreviation: par
• The constraints are defined in detail on a bdd

Image source: [5]

 Requirement Diagram
• Abbreviation: req
• Can be used to express systems
requirements
• Not present in UML, but derived using
stereotyping on the bdd
• Partial overlap with the use case diagram
[5]

Image source: [5]

 Requirement Diagram
• Abbreviation: req
• Relationships:
• Nesting: a requirement may be decomposed
into other requirements
• Derive: a requirement may derive from
another requirement
• Copy: a requirements need to be reused in a
different context
• Verify: used to show how a ‘Test case’ verifies
a ‘Requirement’. It can be used only to relate
a ‘Test case’ and a ‘Requirement’

Image source: [5]

 Requirement Diagram
• Abbreviation: req
• Relationships:
• Satisfy: used to show that a model element
satisfies a ‘Requirement’
• Refine: used to show how a model element
can be used to further refine a ‘Requirement’.
Relates a ‘Requirement’ to a test case
• Trace: used to show that a model element can
be traced to a ‘Requirement’.

Image source: [5]

Requirement Diagram

Image source: [5]

Requirement Diagram

Image source: [5]

Requirement Diagram

Image source: [5]

 Behavioral diagrams
• Sequence Diagram: behavior between elements
• State Machine Diagram: behavior within element
• Activity Diagram: behavior within an operation

• Use Case Diagrams: model requirements and contexts of a system, highest

level of abstraction of a view
 Sequence Diagram
• Abbreviation: sd
• A sequence diagram aims at showing a particular example of operation of a
system, in the same way as moviemakers may draw up a storyboard.
• It is based on the concept of «life line», that is what happens to an «actor» that
interacts with other actors, realizing a «scenario»
• Sequence diagrams model interactions between life lines
Sequence Diagram

Image source: [5]

 Sequence Diagram
• Below a life line there is a dotted
line showing the order in which
events occur
• The line also shows interactions
with other life lines
• A «stop» marks the end of a life line
• The «event occurrence» in the
metamodel shows when a message
occurs to the life line, and is marked
by a message arrow intersecting
the life line

Image source: [5]

 Sequence Diagram
• Examples: interactions between a
robot and its controller
• The horizontal axis shows the
involved actors
• The vertical axis shows the
temporal evolution
• The first frame described the robot
setup
• The second frame describes a time Robot is busy
out scenario, where the robot is
triggered by the operator but stops
itself after a fgiven amount of time
Robot messaging
• The 2nd frame includes a reference itself
to the 1st one
Images’ source: [5]
 Sequence Diagram
• Example: low level control of the
robot motion
• “par” stands for “parallel”, and
implements a “combined fragment”
• The messages in a shaded “par”
area are sent simultaneously (i.e. in
parallel) to motors A and C
• After the turn, the controller restart
forward motion with another “par”
combined fragment

Images source: [5]

 Sequence Diagram
• Example: low level control of the
robot motion
• Checks are possible between the
contend of the sd and the content of
other diagrams.
• The Turn() and Move() messages
appearing in the upper plot were
defined in a bdd.

Images’ source: [5]

 Sequence Diagram
• “pars” may also support looping
(“loop”)
• “alt” denotes the selection between
alternatives
• More language keywords in [8], that
is in https://www.visual-
paradigm.com/guide/sysml/modelin
g-scenarios-with-sequence-
diagram/

Images source: [8]

 State Machine Diagram
• Abbreviation: stm
• Model the behavior during the lifetime of
a block
• Also known as timing models
• Time is “logical”
• Two basic elements: states and transitions

Image source: [5]

 State Machine Diagram
• Abbreviation: stm
• Model the behavior during the lifetime of
a block
• Also known as timing models
• Time is “logical”
• Two basic elements: states and transitions
• Activity: non atomic, can be interrupted
• Action: atomic, cannot be interrupted,
takes no time.
• A transition can include more actions

Image source: [5]

 State Machine Diagram
• Abbreviation: stm
• Rule of thumb that helps ensuring consistency: all
blocks in a system are fully defined if any block that
exhibits behavior (that has operations) has an
associated state machine diagram.

Image source: [5]

 State Machine Diagram
• Example: state machine for the
controller software block previously
shown
• NB: “Moving forward” is a state,
associated to the “do/move”
activity, that will map to an
operation of a block.

Image source: [5]

 State Machine Diagram
• State machines can be written in
terms of states and actions, without
activities (that are interruptable)

Image source: [5]

 Activity Diagram
• Abbreviation: act
• Models workflows or processes
• Activity diagrams derive from flow
charts and can be considered a
specialization of State Machine
Diagrams
• The activity partition introduces the
concept of swim lanes

Images’ source: [5]

 Activity Diagram
• Abbreviation: act
• Models workflows or processes
• Activity diagrams derive from flow
charts and can be considered a
specialization of State Machine
Diagrams
• The activity partition introduces the
concept of swim lanes

Images’ source: [5]

 Activity Diagram
• Abbreviation: act
• Models workflows or processes
• Activity diagrams derive from flow
charts and can be considered a
specialization of State Machine
Diagrams
• The activity partition introduces the
concept of swim lanes
• The meaning of “no buffering” and
“overwrite” is described by the following
example

Images’ source: [5]

 Activity Diagram
• An example: burger production line
• Case 1: customer may eat a 5 minutes
old burger!

Images’ source: [5]

 Activity Diagram
• An example: burger production line
• Case 2: customer always eat a fresh
burger, but at a price of waste!

Images’ source: [5]

 Activity Diagram
• An example: burger production line
• Case 3: customer always eat a fresh
burger, but at a price of waste!

Images’ source: [5]

 Activity Diagram
• Use of an activity diagram to model an
operation

Images’ source: [5]

 Activity Diagram
• Use of an activity diagram to model a
low-level conceptual operation

Images’ source: [5]

 Activity Diagram
• Use of an activity diagram to model a workflow
(ISO style), partitioning in swim lanes

Images’ source: [5]

 Activity Diagram
• Use of an activity diagram to model a workflow
(RUP style), using the “fork” and the “join” features

• RUP: Rational Unified Process

Images’ source: [5]

 Use Diagram
• Abbreviation: uc
• Metamodel and symbols:

Images’ source: [5]

 Use Diagram
• Abbreviation: uc
• Relationships with other diagrams

Images’ source: [5]

 Use Diagram
• An example:

Images’ source: [5]

 Use Diagram
• An example:

Images’ source: [5]

 Use Diagram
• An example:

Images’ source: [5]

 References
1) https://sysml.org/sysml-faq/what-is-sysml.html
2) https://sysml.org/
3) https://www.omg.org/
4) https://www.omgsysml.org/what-is-sysml.htm
5) Jon Holt and Simon Perry, SysML for Systems Engineering, IET Professional Applications of Computing Series 7, ISBN 978-0-86341-825-9
6) https://www.researchgate.net/publication/262401126_Compositional_Verification_of_Architectural_Models/figures?lo=1

7) https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/session-3-systems-modeling-languages/
8) https://www.visual-paradigm.com/guide/sysml/modeling-scenarios-with-sequence-diagram/