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/
