Applying SysML with MAGICDRAW

title: Applying SysML with MAGICDRAW
author: Filip Stachecki (NobleProg) filip@nobleprog.pl

</slideshow>

Copyright Notice

This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.

Table of contents⌘

SysML Introduction	3
SysML Model Elements	15
SysML Package Diagram	20
SysML Use Case Diagram	31
SysML Requirements	47
SysML Block Definition Diagram	66
SysML Internal Block Diagram	86
SysML Parametric Diagram	91
SysML State Machine Diagram	95
SysML Activity Diagram	114
SysML Sequence Diagram	143
SysML Allocations	158
Further Reading	162

SysML Introduction⌘

Copyright ⌘

Most of our training material is based on the OMG's SysML Specification http://www.omg.org/spec/SysML

SysML⌘

Systems Modeling Language
OMG specification, current version: 1.5, release date: May 2017
http://www.omg.org/spec/SysML/Current
SysML is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities.
SysML provides semantics (meaning) and notation (representation of meaning).
SysML is methodology and tool independent

Systems Engineering⌘

Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle.
This process is usually comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate.

source: http://www.incose.org/

DBSE vs. MBSE⌘

Document-based systems engineering approach uses textual documents that are exchanged between stakeholders
Model-based systems engineering uses systems modeling as a part of the SIMILAR process.
System model includes system specification, analysis, design, ... and is stored in a repository.

The four pillars of system modelling⌘

SysML/UML Interrelationship⌘

SysML reuses a subset of UML 2 and provides additional extensions needed to address requirements of Systems Engineering.

SysML diagrams⌘

SysML diagram frame⌘

<headingName> ::== 
  <diagramKind> ['['modelElementType']'] <modelElementName> ['['diagramName']']

The frame is a rectangle that is required for SysML diagrams (Note: the frame is optional in UML).

Diagram Kind⌘

SysML diagram kinds should have the following names or (abbreviations) as part of the heading:
- activity diagram (act)
- block definition diagram (bdd)
- internal block diagram (ibd)
- package diagram (pkg)
- parametric diagram (par)
- requirement diagram (req)
- sequence diagram (sd)
- state machine diagram (stm)
- use case diagram (uc)

Diagram Frame example⌘

The Four Pillars of SysML⌘

source: http://www.omgsysml.org/

SysML Model Elements⌘

Comment⌘

Comments can be associated with any model element and are quite useful as an informal means of documenting the model.
SysML has introduced extensions to a comment called: Rationale, Problem and ElementGroup

Problem and Rationale⌘

A Rationale is used to facilitate the system modeler in capturing decisions.
The rationale may be attached to any entity, such as a system element (block), or to any relationship, such as the satisfy relationship between a design element and a requirement.
A Problem documents a deficiency, limitation, or failure of one or more model elements to satisfy a requirement or need, or other undesired outcome. It may be used to capture problems identified during analysis, design, verification, or manufacture and associate the problem with the relevant model elements.

Problem and Rationale example⌘

Constraint⌘

Constraints are used to capture simple constraints associated with one or more model elements

SysML Package Diagram⌘

Package⌘

A Package is used to group elements, and provides a namespace for the grouped elements.
All the members of a namespace are distinguishable within it. A Packageable Element is a model element that may be owned directly by a Package.
The visibility of a packaged element (private or public) may be used to specify which elements can be imported into another package (default public)
A qualified name syntax:

package name::element name

Package nesting⌘

Packages support package hierarchies.

Package relationship⌘

Some elements from package B depends on some elements from package A

Package Import, Access⌘

A package import is defined as a directed relationship that identifies a source package whose members are to be imported by a target namespace.

Two types:

«import» for a public package import
- transitive: if A imports B and B imports C then A indirectly imports C
«access» for a private package import
- intransitive (elements are imported as private members of the target package)

Package Import Example 1⌘

elements in Types are imported to ShoppingCart, and then further imported to WebShop
elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced from WebShop

Package Import Example 2⌘

Model⌘

A Model is a description of a system - not only software and hardware but organizations and processes.
It describes the system from a certain viewpoint, for a certain category of stakeholders, and at a certain level of abstraction.
A Model is a Package.

Package diagram example⌘

Stakeholder, View and Viewpoint⌘

A stakeholder represents a role, group, or individual who has concerns that will be addressed by the View of the model.
A view is a representation of the system from defined viewpoint.
The viewpoint describes the point of view of a set of stakeholders, specifies conventions and rules for constructing and using a view.

View and Viewpoint example⌘

SysML Use Case Diagram⌘

Use Case Diagram key concepts⌘

Use cases are used to model the requirements of a system (what a system is supposed to do)
The key concepts associated with use cases are actors, use cases, and the subject.
Use Case Diagram describes the relationships among a set of use cases and the actors participating in these use cases
it does NOT describe behavior or flows (WHO and WHAT, not HOW)

Actor⌘

a role played by an external entity - a user or any other system that interacts with the subject
may represent roles played by human users, external hardware, or other subjects
Notation: "stick man" icon (with the name above or below) or a rectangle

Relationships Between Actors⌘

Generalization
Specialization

UseCase⌘

the specification of a set of actions performed by a system and producing a result
a complete set of actions that perform a function for a particular actor
Notation: an ellipse (with the name inside or below) or a rectangle with a stereotype

Subject⌘

a system (subject) is a box containing use cases
defines boundaries and responsibilities
actors are always external to a system
the subject rectangle does not imply that the subject classifier owns the contained Use Cases,

Relationships Between Actors and Use Cases⌘

an association expresses a communication path between the actor and the use case
directed association from the active to the passive element (who initiated the communication)
association with multiplicity like 0..*, 2..*, *, etc
- at the actor end - more than one actor instance is involved in initiating the use case
- at the use case end - an actor can be involved in multiple use cases of that type

Relationships Between Use Cases⌘

Three types of relationship:

«include»
«extend»
generalization / spacialization

Include⌘

defines that a use case contains the behavior defined in another use case
behavior of the included use case is inserted into the behavior of the including use case
included use case is not optional, and is always required

Include - common part⌘

include relationship is intended to be used when there are common parts of the behavior of two or more use cases
this common part is then extracted to a separate use case, to be included by all the base use cases having this part in common

Include Example⌘

basic flow of events is incomplete without the inclusion

Extend⌘

a relationship from an extending use case to an extended use case
specifies how and when the behavior defined in the extending use case can be inserted into the extended use case
the extension takes place at extension point
basic flow of events should still be complete

Extension Point⌘

Generalization⌘

the specific use case inherits the features of the more general use case

Abstract Use Case⌘

does not provide a complete declaration and can typically not be instantiated
is intended to be used by other use cases, e.g., as a target of generalization relationship
the name of an abstract Use Case is shown in italics

Use Case Diagram Example⌘

SysML Requirements⌘

A Requirement⌘

A requirement specifies a capability or condition that must (or should) be satisfied.
A requirement may specify a function that a system must perform or a performance condition a system must achieve.
SysML provides modeling constructs to represent text-based requirements and relate them to other modeling elements.
The requirements diagram can depict the requirements in graphical, tabular, or tree structure format.
A requirement can also appear on other diagrams to show its relationship to other modeling elements.

Requirements Tabular Representation⌘

Requirements relationships⌘

Several requirements relationships are specified that enable the modeler to relate requirements to other requirements as well as to other model elements.
These include relationships for defining a requirements hierarchy, deriving requirements, satisfying requirements, verifying requirements, and refining requirements.

requirement containment⌘

A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism.
This relationship enables a complex requirement to be decomposed into its containing child requirements.

requirement containment example⌘

A Package Containing Requirements⌘

copy⌘

A Copy relationship is a dependency between a supplier requirement and a client requirement that specifies that the text of the client requirement is a read-only copy of the text of the supplier requirement.

copy example⌘

deriveReqt⌘

A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement.
For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement.
The arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived.

deriveReqt example⌘

deriveReqt & problem example⌘

satisfy⌘

A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement.
The arrow direction points from the satisfying (client) model element to the (supplier) requirement that is satisfied.

verify⌘

A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement.
The arrow direction points from the (client) element to the (supplier) requirement.

refine⌘

The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement.
For example, a use case or activity diagram may be used to refine a text-based functional requirement.

Example⌘

trace⌘

A generic trace requirement relationship provides a general-purpose relationship between a requirement and any other model element.
The semantics of trace include no real constraints and therefore are quite weak.
It is recommended that the trace relationship not be used in conjunction with the other requirements relationships.

Requirement relationships as matrices⌘

Non-normative Requirements subclasses⌘

Annex E: Non-normative Extensions of the SysML specification describes an example of a non-normative extension for a requirements profile.
More specialized requirement stereotypes are introduced: functional, interface, performance, physical, design constraint.
Additional properties are proposed: source, risk, and verifyMethod

SysML Block Definition Diagram⌘

Block Definition Diagram⌘

The Block Definition Diagram in SysML defines features of blocks and relationships between blocks such as associations, generalizations, and dependencies.
It captures the definition of blocks in terms of properties and operations, and relationships such as a system hierarchy or a system classification tree.

Block⌘

Blocks are modular units of system description.
Each block defines a collection of features to describe a system or other element of interest.
These may include both structural and behavioral features, such as properties and operations
SysML allows blocks to have multiple compartments appearing in any order, each optionally with name.
In SysML all properties of a block have the visibility public.

Block structure compartment⌘

A compartment with the label “structure” may appear as part of a block definition to show connectors and other internal structure elements for the block being defined.

Relationships⌘

Generalization⌘

relationship between a more general classifier and a more specific classifier
each instance of the specific classifier is also an indirect instance of the general classifier
the specific classifier inherits the features of the more general classifier

Association⌘

A unidirectional association has a default multiplicity of 1 on its target end.

Part/Shared Association⌘

A part or shared association has a default multiplicity of [0..1] on the black or white diamond end.

Containment⌘

ValueType⌘

A ValueType defines types of values that may be used to express information about a system but has no identity.
SysML defines ValueType as a stereotype of UML DataType.
For example, the SysML “Real” ValueType expresses the mathematical concept of a real number, but does not impose any restrictions on the precision or scale of a fixed or floating-point representation that expresses this concept.

Primitive Value Types⌘

Enumeration⌘

An Enumeration is a Value Type whose values are enumerated in the model as literals.

Unit and QuantityKind⌘

A QuantityKind is a kind of quantity that may be stated by means of defined units.
For example, the quantity kind of length may be measured by units of meters, kilometers, or feets.

Unit and QuantityKind example⌘

Ports and Flows⌘

Ports and flows are useful to enable design of modular, reusable blocks with clearly defined ways of connecting and interacting with their context of use.
Flow properties specify the kinds of items that might flow between a block and its environment, whether it is data, material, or energy.
The kind of items that flow is specified by typing flow properties.

Item Flow⌘

Item flows specify the things that flow between blocks and/or parts and across associations or connectors.
Item flows specify what “does” flow between blocks and/or parts in a particular usage context, e.g. water or gasoline.

Port⌘

Ports are points at which external entities can connect to and interact with a block in different or more limited ways than connecting directly to the block itself.
They are properties with a type that specifies features available to the external entities via connectors to the ports.
SysML identifies two kinds of ports:
- proxy port - exposes features of the owning block or its internal parts
- full port - supports its own features, specifies separate elements of the system
Proxy ports are always typed by interface blocks, a specialized kind of block that has no behaviors or internal parts.
Ports that are not specified as proxy or full are simply called “ports.”

Interface⌘

An Interface represents a declaration of a set of public Features and obligations that together constitute a coherent service.
The set of Interfaces realized by a block are its Provided Interfaces, which represent the services and obligations that instances of that block offer to their clients.
Required Interfaces specify services that a block needs in order to perform its function and fulfill its own obligations to its clients.

Instance Specification⌘

An Instance Specification is a model element that represents an instance in a modeled system.
They are often used to model example configurations of instances.
They may be partial or complete representations of the instances that they correspond to.

Constraint Blocks⌘

Constraint blocks provide a mechanism for integrating engineering analysis such as performance and reliability models with other SysML models.
Can be used to specify constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}.
Is a block that contains the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks.
Can be defined on Block Definition Diagram or Package Diagram and used on Parametric Diagrams

SysML Internal Block Diagram⌘

The Internal Block Diagram in SysML captures the internal structure of a block in terms of properties and connectors between properties.
An internal block diagram is based on the UML composite structure diagram, with restrictions and extensions as defined by SysML.
All the properties and connectors that appear inside the internal block diagram belong to the block that is named in the diagram heading name.

Property⌘

A property can represent a role or usage in the context of its enclosing block.
A reference property is shown by a dashed-outline box.
Ports are special cases of properties.

Nested Property⌘

A property name shown inside or outside the property box may take the form of a multi-level name.
This form of name references a nested property.
The name of the property is built by a string of names separated by “.”.

BDD/IBD Example⌘

Structure of Power Subsystem (Block Definition Diagram)

IB Diagram for the “Power Subsystem”⌘

SysML Parametric Diagram⌘

Parametric diagrams model a network of constraints on system properties to support engineering analysis, such as performance, reliability, and mass properties analysis.
Parametric diagrams is a restricted form of internal block diagram that includes usages of constraint blocks.

Constraint Property⌘

A constraint property may be shown on a parametric diagram using a rectangle with rounded corners.
This graphical shape distinguishes a constraint property from all other properties and avoids the need to show an explicit «constraint» keyword.
A value property may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box.

Parametric diagram example⌘

source: Tim Weilkiens, Systems Engineering with SysML/UML, Morgan Kaufmann OMG Press

Parametric diagram example⌘

source: SysML specification

SysML State Machine Diagram⌘

State machine diagram is a behavior diagram which shows discrete event-driven behavior of a part of designed system through finite state transitions.
The UML concept of protocol state machines is excluded from SysML to reduce the complexity of the language.

Vertex⌘

Vertex is named element which is an abstraction of a node (State or Pseudostate) in a state machine graph.
It can be the source or destination of any number of transitions.

State⌘

State models a situation during which some invariant condition holds.
In most cases this condition is not explicitly defined.

Transition⌘

Directed relationship between a source vertex and a target vertex.
Syntax: [<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
- trigger specifies events that may cause state transition,
  - SignalEvent triggers and CallEvent triggers are not distinguishable by syntax
- guard is a boolean expression,
- optional behavior-expression is an expression specifying the effect (is executed when the transition fires)

Transition Kind⌘

The semantics of a Transition depend on its relationship to its source Vertex:

external - transition exits its source vertex (executes exit action of source state)
local - transition does not exit its containing State (exit action of the containing state will not be executed)
- Target vertex may be different from its source Vertex.
- Local transition can only exist within a composite State.
internal is a special case of a local transition with the same source and target states,
- the state is never exited (and not re-entered)
- no exit or entry actions are executed

Internal Transition example⌘

source: wikipedia.org

Internal Behaviors⌘

syntax: <behavior-type-label> ['/' <behavior-expression>]
entry - a Behavior which is performed upon entry to the State (entry Behavior).
do - starts execution when the State is entered, (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
- it completes (in which case a completion event is generated) or
- the State is exited, in which case execution of the doActivity Behavior is aborted.
exit - a Behavior that is performed upon exit from the State (exit Behavior).

Pseudo State⌘

Pseudostate is an abstract vertex that describes different types of transient vertices in the state machine graph.
Pseudostates are transitive - a compound transition execution simply passes through them, arriving on an incoming Transition and leaving on an outgoing Transition without pause.

Initial ⌘

Initial Pseudostate represents a starting point for a Region.
It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.
There can be at most one initial Vertex in a Region.

Choice⌘

Choice is used to realize a dynamic conditional branch.
It allows splitting of compound transitions into multiple alternative paths.
The decision on which path to take may depend on the results of Behavior executions performed in the same compound transition prior to reaching the choice point.
If more than one guard evaluates to true, one of the corresponding Transitions is selected.
If none of the guards evaluates to true, then the model is considered ill formed

Junction ⌘

Junction can be used to merge multiple incoming Transitions into a single outgoing Transition or,
it can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints.
Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch.

Fork⌘

Splits an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State.
The Transitions outgoing from a Fork cannot have a guard or a trigger.

Join⌘

Common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions.
Transitions terminating on a Join cannot have a guard or a trigger.

Terminate ⌘

Execution of the State Machine is terminated immediately.
The State Machine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are automatically aborted.

Entry Point ⌘

Represents an entry point for a State Machine or a composite State that provides encapsulation of the insides of the State or StateMachine.
In each Region of the StateMachine or composite State owning the Entry Point, there is at most a single Transition from the entry point to a Vertex within that Region.

If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. If multiple Regions are involved, the entry point acts as a fork Pseudostate.

Exit Point ⌘

Represents an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or State Machine.
Transitions terminating on an exit point within any Region of the composite State or a State Machine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior).

If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Psuedostate.

Shallow History⌘

Represents the most recent active substate of its containing Region, but not the substates of that substate.
Transition terminating on this Pseudostate implies restoring the Region to that substate.
A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State.
Shallow History can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State.

Deep History⌘

Represents the most recent active state configuration of its owning Region.
Transition terminating on this Pseudostate implies restoring the Region to that same state configuration.
The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State.
Deep History Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State.

Final State⌘

Final State is a special kind of State (not Pseudo State) signifying that the enclosing Region has completed.
Transition to a Final State represents the completion of the behaviors of the Region containing the Final State.

STM Diagram example⌘

SysML Activity Diagram⌘

Flow-based logic⌘

Activity modeling specifies controlled sequences of actions, inputs and outputs.
Activity diagram is primary representation for modeling flow-based logic.

Activity, Action⌘

Activity

describes a sequence of actions based on control models and object flow models
contains edges and activity nodes (e.g. actions), is represented by a rectangle with rounded corners

Action

is a fundamental unit of executable functionality contained within an Activity
represents a single step within an activity

Activity Node ⌘

Subtypes of Activity Node

Activity Edge⌘

The edges of an activity
Denoted by a straight line with an open arrowhead

Control Flow⌘

A control flow is an edge that starts an activity node after the previous one is finished
In SysML a control flow may be notated with a dashed line and stick arrowhead

Object Flow⌘

OR

An object flow is an activity edge that can have objects or data passing along it

Control Nodes⌘

Control Node is used to manage the flow of tokens between other nodes in an Activity.

Initial Node⌘

It has outgoing edges but no incoming edges
An activity may have more than one initial node
- Each generates a concurrent flow
An initial node can have more than one outgoing edge
- Semantics: a control token at ONLY ONE outgoing edge
Activity diagrams do not have to have initial nodes
Notation: a filled circle

Activity Final Node⌘

An activity may have more than one activity final node
The first one reached stops all flows in the activity
- Regardless of the number of tokens in activity
At least one incoming edge and no outgoing edges
If several incoming edges only one must carry a token
Activity diagrams do not have to have final nodes
Notation: a filled circle with an outer ring

Flow Final Node⌘

A Flow Final Node is a Final Node that terminates a flow by consuming the tokens offered to it without any effect on execution of the enclosing activity.

Decision⌘

is a control node that chooses between outgoing flows
One incoming edge and several outgoing edges
When a token is supplied guards on outgoing edges are evaluated
- Token goes to first true outgoing
Notation: a rhombus

Merge⌘

A merge node is a control node that brings together multiple alternate flows
- It is not used to synchronize concurrent flows
Several incoming edges, one outgoing edge
Nothing calculated, nothing expected
Notation: an empty rhombus
incoming to and outgoing from a Merge must be either all Object Flows or all Control Flows.

Fork, Join⌘

Fork – one incoming edge and multiple outgoing edges
Join – multiple incoming edges and one outgoing edge

Call Behavior Action⌘

Call Behavior Action invokes a Behavior directly

Send Signal Action⌘

Send Signal Action creates a Signal instance and transmits the instance to the object given on its target

Accept Event Actions⌘

Accept Event Action waits for a specific event to occur.

Accept Event Actions examples⌘

Interruptible Region⌘

An Interruptible Region is a group that supports termination of a portion of an Activity.

SysML Activity extensions⌘

SysML provides some extensions to UML Activity diagrams:

extensions to UML flows:
- Probability
- Rate
Optional parameter
Activities as blocks (function tree)

Probability⌘

The «probability» stereotype can be applied to edges coming out of decision nodes and object nodes.
It provides an expression for the probability that the edge will be traversed.
These must be between zero and one inclusive, and add up to one for edges with same source at the time the probabilities are used.

Rate / Frequency⌘

When the «rate» stereotype is applied to an activity edge, it specifies the expected value of the number of objects and values that traverse the edge per time interval, that is, the expected value rate at which they leave the source node and arrive at the target node.
Two kinds of rate: continuous or discrete
Continuous rate is intended to represent continuous flows that may correspond to water flowing through a pipe, or continuous energy flow.

Optional parameter⌘

When the «optional» stereotype is applied to parameters, the lower multiplicity must be equal to zero.
This means the parameter is not required to have a value for the activity or any behavior to begin or end execution.

Activities as blocks⌘

Activities in block definition diagrams appear as regular blocks with the «activity» keyword

Linking activities to structural elements⌘

Activities can be used without any reference to existing structural model elements.
there are some possibilities how to link them to those elements:
- using activity partitions
- using behaviors for blocks
- using methods
- using activities as part of transition description on state machine diagram

Behaviors for blocks⌘

Activities as Methods⌘

Partitions⌘

State Machine transition⌘

SysML Sequence Diagram⌘

Sequence Diagram⌘

Participants are represented by lifeline - a rectangle and a dashed line
Messages are represented by arrows between lifelines
Lifeline describes the time-line for a process, where time increases down the page
The entire diagram represents one interaction

Lifeline⌘

Lifeline

a set of instances
can be considered as objects of the specified type
represents a participant

Occurrence Specification ⌘

Occurrence Specification represents a moment in time at the beginning or end of a message or at the beginning or end of an execution.
The semantics of an Interaction is given as a trace (a sequence of event occurrences).

Execution Specification ⌘

Specification of the execution of a unit of behavior within the lifeline.
Sending and receiving messages determine start and end of execution specification.

Message⌘

Message Types⌘

Synchronous message (filled arrowhead):
- caller waits until called behavior terminates
- reply message is represented by dashed line with either an open or filled arrow head
Asynchronous message (open arrowhead):
- caller doesn't wait but continues after call, no reply
Found message (open arrowhead originating from a filled circle):
- receiver known, sender not known
Lost message (open arrowhead pointing to a filled circle)
- sender known, receiver not known
Create message (dashed line with open arrowhead pointing to header of lifeline):
- new lifeline is created at this point in the diagram
Delete message (open arrowhead):
- object destruction, stop (destruction of an object is represented by a cross on the lifeline)

Event Occurrences⌘

Sequence of event occurrences (trace) is defined by <eventoccurrence1, eventoccurrence2, ...,eventoccurrence-n>
send event is denoted by an exclamation mark (!p)
receive event is denoted by question mark (?p)
A valid sequence for the interaction: < !p, ?p, !q, ?q >
It's not the only valid sequence!

Event Occurrences valid trace⌘

Event Occurrences Rule⌘

Send event before receive event
The order of events along one lifeline is relevant.
The position of one event relative to an event on another lifeline is insignificant.

Fragments⌘

Combined Fragment is an interaction fragment which defines a combination (expression) of interaction fragments.
- Interaction Operator specifies the meaning of Combined Fragment
- Interaction Operands are separated by a dashed horizontal line. The Interaction Operands together make up the framed Combined Fragment
- Interaction Constraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event

Interaction Operator Kind⌘

Only one operand fragments		One or more operands fragments
opt - option	neg - negative	alt - alternatives
break	assert - assertion	par - parallel
loop- iteration	consider	strict - strict sequencing
critical	ignore	seq - weak sequencing

Interaction Use⌘

Interaction Use is an interaction fragment which allows to use another interaction.
It is shown as a Combined Fragment symbol where the operator is called ref.

Interaction Use referring the Interaction EstablishAccess with (input) argument “Illegal PIN.” Within the optional CombinedFragment there is another Interaction Use without arguments referring OpenDoor

Interaction Use example⌘

Sequence diagram example⌘

SysML Allocations⌘

Allocation is cross-association (mapping) of elements within the various structures or hierarchies of a user model.
The allocation relationship can provide an effective means for navigating the model by establishing cross relationships, and ensuring the various parts of the model are properly integrated.
Allocate is a dependency based on UML::Abstraction.
Based on the picture above:
- The Client element is allocated to the Supplier element.
- The Supplier element is allocated from the Client element.