Block definition diagrams in the Systems
Modeling Language (SysML)
Student: Nick Jansen 4004736
Student assistant: Dimitra Papachristou
Introduction Friedenthal, Moore, & Steiner (2014, p. 3) define the systems modeling language (after now SysML) as
“a general-purpose graphical modeling language for representing systems that may include combinations
of hardware, software, data, people, facilities, and natural objects”. Important to notice is that the
definition says just systems and not software systems. This means the language can be used to model any
kind of system and is not solely focused on software. A system can be anything, there are e.g. nervous
systems, pipe systems, democratic systems, postal systems, inventory systems etc. Because a system is
such a broad concept it is expected that a language like SysML trying to model such a concept is very
high level/generic, which SysML actually is. SysML is a combination of nine diagrams: the package,
requirement, activity, sequence, state machine, use case, block definition, internal block and parametric
diagram. Each diagram represents a different aspect of a system. These diagrams have a big overlap with
the well-known Unified modeling language UML.
Figure 1 Overlap between UML & SysML
The package, sequence, state machine and use case diagrams are the same as in the likewise named
diagrams in UML. The activity, block, and internal block diagrams are modifications of diagrams in
UML. The requirement and parametric diagram do not exist in UML. This paper focuses on the block
diagrams and therefore, there will not elaborate on all SysML’s diagrams.
Block diagrams Block diagrams are the principle structural diagrams in SysML. They are used in SysML to model the
structure of a system in a hierarchical way. There are numerous different types of blocks in SysML but
because of the limited space in this paper, only the basic block node will be explained. The block node is
the fundamental modular unit in SysML for describing a system (Friedenthal, Moore, & Steiner, 2014). A
block node always consists of one mandatory compartment and of several optional compartments of
which the three most important will be discussed. The mandatory compartment is the name compartment,
in the name compartment first the type of block is defined between double brackets. In this case that is
just “<<block>>” because we are discussing the most basic block, other block types in SysML are for
example <<valueType>>, <<enumeration>>, <<interface>>, <<signal>>, <<constraint>> and more.
Followed by the block type is the name of the block, this is the one value a block must always have. Even
the block type (<<block>>) is not always defined, this is the case when a diagram is created with only
basic block instances then it is only needed to provide each block with a name.
Parameters The first optional compartment to be discussed is parts, the parts compartment contains all relevant parts
of which a block can consists. When listing a part in the parts compartment, an instance of an already
defined block is created, to which is referred by the block name. It is not mandatory to give each part a
part name. The listed parts have to follow the notation:
Part name: block name [multiplicity]
The second optional compartment is references. References are used to refer to other blocks to which the
block has a connection to but does not depend on. This way when the referred to block gets destroyed the
block with the reference can continue to exist. When the association would be a part instead of a
reference the block would also get destroyed. The listed references have to follow the notation:
Reference name: block name [multiplicity]
The third optional compartment is values. Values are used to store quantitative information about a block,
for example weight, velocity or temperature. Value types first have to be defined before they can be used,
except for the predefined primitive types in SysML (Integer, String, Boolean, Real). The listed values
have to follow the notation:
Property name: type name = default value
In figure 2 there is an example of the most basic block with all the compartments.
«block»Name
PartsPart name: block name [multiplicity]
ReferencesReference name: block name [multiplicity]
ValuesProperty name: type name = default value
Figure 2 Example of a basic block in SysML
Associations Apart from blocks a block definition diagram also has associations between blocks. There are composite
associations and reference associations. The composite associations are used to create a hierarchy of
blocks. Figure 4 shows an example of a composite association arrow. The left side of the filled diamond is
used at the composite block and the right side with the arrow at the part side. Multiplicity can also be
shown at both ends of the association.
Figure 4 Example of a composite association
Reference associations are used to show one block uses another block as a reference. This can go one way
were the one block only uses the other block or both ways where they use each other. The notation for a
one-way reference is shown in figure 5 where the referred to block is on the right side and the notation for
a two-way reference is shown in figure 6.
Figure 5 Example of a one-way reference association
Figure 6 Example of a two-way reference association
The last association to be discussed is the generalization, shown in figure 7. A generalization arrow is
used to specify a specialized instance of a more general block. It points from the specialized block to the
general block.
Figure 7 Example of a generalization association
Procedure In a normal SysML project there is a certain order in which the different diagrams are constructed.
Normally this starts with the creation of the requirements diagram. From the requirements diagram the
system activity diagram is created in which the stated requirements gets satisfied by introducing systems
which have a certain behavior with each other. These systems all consist of several components, the
interactions of these components with each other are modeled in a more specific component activity
diagram. The system activity diagram and the component activity diagram together make up the behavior
package in the overarching package diagram. When this it finished the block definition diagrams can get
created, they are created based on the information of the activity diagrams. In the simplest case the
procedure is as follows:
1) Identify all the systems from the systems activity diagram and create blocks representing them.
2) Identify all the components from the component activity diagram and create blocks representing
them.
3) Fill the blocks with the appropriate parameters named values in SysML.
4) Draw the relevant associations between the different blocks.
After following these steps the block definition diagram is created. From this diagram it is possible to also
create an internal block diagram and a parametric diagram. But because these diagrams lay outside the
scope of this paper they will not be discussed.
Example In figure 8 an example of a block definition diagram is shown for a headphone system. The block named
Headphones is the generalized block with the general parts and values all headphones have. In this case 2
speakers an electronic circuit and a casing, also they both have a max volume defined in decibels. The
two other blocks Wired Headphone and Wireless Headphones contain a specialized version of
headphones with both specialized parts and values. The arrow indicates that the block Headphones is a
generalization of Wired headphones and Wireless Headphones.
«block»Headphones
parts:Speakers 2:Electronic Circuit:Casing
ValuesMax volume : dB
«block»Wired Headphones
«block»Wireless Headphones
Parts:Cable
Parts:Battery:Bluetooth Card
ValuesBattery life : s
ValuesCable length : cm
bdd [Package] Physical [Specialized Headphones]
Figure 8 Example of a block definition diagram
Process-Deliverable Diagram For further explanation of the structure and processes of block definition diagrams a process deliverable
diagram (after now PDD) is created. A PDD is a model created to integrate the activities and the
deliverables from a method. It consist of the PDD, two accompanying tables (the activity table and the
concepts table) and optionally a meta-model of a certain concept in the model. Weerd & Brinkkemper
came up with the idea of PDD’s, for more extensive explanation read their article (Weerd &
Brinkkemper, 2008).
OSEEM Because a PDD is used to model a method and not a technique, a method that uses the block definition
diagrams is needed. For the paper there is chosen to use the Object-Oriented Systems Engineering
Method (OOSEM) to display the technique of block definition diagrams. Friedenthal, Moore, & Steiner
(2014, p. 431) define OOSEM as “a top-down, scenario-driven process that uses SysML to support the
analysis, specification, design, and verification of systems”. It is a method used for the complete
development cycle of any system. Because it covers all these subjects OOSEM is a very extensive
method, therefore a method fragment is picked that is the most relevant to the block definition diagrams.
This method fragment is called define logical architecture in OOSEM. Figure 9 gives a global overview
of all the processes in OOSEM at a very high level. The figure displays that the defining of the logical
architecture is at the hearth of the process, likewise the block definition diagrams in SysML.
Figure 9 Overview of all the global activities in OOSEM
PDD description The PDD is created for the define logical architecture method fragment of OOSEM, it can be found in
figure 10.
The first activity of the PDD is Define logical decomposition, during this activity the LOGICAL
DECOMPOSITION BDD is created. This concept is a block definition diagram and therefore inherits all
the characteristics of the concept BLOCK DEFINITION DIAGRAM, this concept is elaborated in figure
11, which is the meta-model of block definition diagrams. The LOGICAL DECOMPOSITION BDD
consist of one or more LOGICAL COMPONENTS which therefore are created at the same time. These
components can be EXTERNAL INTERFACE- APPLICATION- or INFRASTRUCTURE
COMPONENTS.
When the LOGICAL DECOMPOSITION BDD is created a cycle is initiated containing two activities.
First the Define interaction between logical components activity in which an ACTIVITY DIAGRAM is
created for a specific system function. These ACTIVITY DIAGRAMS consist of ACTIVITY
PARTITIONS which are a representation of the LOGICAL COMPONENTS1. The next activity is
Define logical internal block diagram, in this activity an INTERNAL BOCK DIAGRAM is created. This
diagram elaborates on all the LOGICAL COMPONENTS and by doing so it gives an overview of the
more specific internal workings of the system2. These two activities keep getting repeated until all the
system functions are analyzed.
When all system functions are analyzed the Specify logical components activity is started, during this
activity a specification is written for each LOGICAL COMPONENT. It can be the case that a LOGICAL
COMPONENT includes a sate machine, this is checked in the last activity Define logical component state
machine. This activity creates a LOGICAL SATE MACHINE for a LOGICAL COMPONENT
SPECIFICATION. After completing this step the Define logical architecture method fragment of
OOSEM is completed.
Although some activities may seem quite high-level they are actually the most fundamental activities in
OSEEM according to the documentation (Friedenthal, Moore, & Steiner, 2014). Therefore they are
modeled just as standard activities.
1 ACTIVITY DIAGRAMS include more concepts, but these concepts are not relevant for the paper and
therefore left out to keep to model clear.
2 INTERNAL BLOCK DIAGRAMs consist of more concepts than just LOGICAL COMPONENTS, but
these concepts are not relevant for the paper and therefore left out to keep to model clear.
Figure 10 Process-Deliverable Diagram of Define logical architecture process
Activity Sub-Activity Description
Define logical architecture
Define logical decomposition
A Sysml LOGICAL DECOMPOSITION BDD is created. It represents the system devided in LOGICAL COMPONENTS. It gives a global overview of the system. It is conducted by the system architect.
Define interaction between logical components
A SysML ACTIVITY DIAGRAM is created. An ACTIVITY DIAGRAM has several different swim lanes called ACTIVITY PARTITIONS which represent LOGICAL COMPONENT's. It is conducted by the system architect.
Define logical internal block diagram
The INTERNAL BLOCK DIAGRAM is created in which all the relations between in the LOGICAL COMPONENTS are defined. It is conducted by the system architect.
Specify logical components
A specification of all the LOGICAL COMPONENT's is written. It is conducted by the system architect.
Define logical component state machine
In case LOGICAL COMPONENT's have a state machine, this is defined at this step. It is conducted by the system architect.
Table 1 Activity diagram PDD
Concept Description
BLOCK DEFINITION DIAGRAM This concept represents the meta-model of a BDD, it refers to figure 11. The LOGICAL DECOMPOSITION BDD is a specialization of this concept.
LOGICAL DECOMPOSITION BDD In this concept the whole system comes together, it is a specialized BDD where all the LOGICAL COMPONENTS are connected to a system as a whole.
LOGICAL COMPONENT A LOGICAL COMPONENT is a functional part of the system but not necessarily a physical part.
EXTERNAL INTERFACE COMPONENT LOGICAL COMPONENT specialization which is responsible for the interface to external systems or users.
APPLICATION COMPONENT LOGICAL COMPONENT specialization which manages the business logic and processing.
INFRASTRUCTURE COMPONENT LOGICAL COMPONENT specialization that supports internal infrastructure connections in the system.
ACTIVITY PARTITIONS Are the swim lanes in the ACTIVITY DIAGRAM, they represent LOGICAL COMPONENT's
ACTIVITY DIAGRAM SysML ACTIVITY DIAGRAM it is a diagram about all the actions a system can undertake.
INTERNAL BLOCK DIAGRAM SysML INTERNAL BLOCK DIAGRAM in which all the relations between the LOGICAL COMPONENT's are made clear.
SUBSET VIEW OF INTERNAL BLOCK DIAGRAM
A view on a part of the INTERNAL BLOCK DIAGRAM.
LOGICAL COMPONENT SPECIFICATION
A documented specification for each LOGICAL COMPONENT.
LOGICAL STATE MACHINE Documentation about the possible state behavior a LOGICAL COMPONENT can have.
Table 2 Concept table of PDD
Meta-model description A meta-model is created for the block definition diagrams (figure 10). This meta-model is a
generalization of the LOGICAL DECOMPOSITION BDD of the PDD. The meta-model contains two
main elements, the BLOCK and the ASSOCIATION, both have several specific versions. The BLOCK
(UNIT BLOCK, VALUE TYPE BLOCK, BASIC BLOCK, ENUMERATION BLOCK and ACTOR
BLOCK) and the ASSOCIATION (COMPOSITE, REFERENCE and GENERALIZATION) the
REFERENCE is a generalization of the TWO-WAY REFERENCE and the ONE-WAY REFERENCE.
Zero too many BLOCKS have 1 to many ASSOCIATIONS and zero too many ASSOCIATIONS relate
to one or two BLOCKS. A BLOCK DEFINITION DIAGRAM consist of one or more BLOCKS.
The most important elements of the BDD are covered in this meta-model. Covering the complete meta-
model of the BDD would not fit in the scope of this paper because of the extensive possibilities within the
language (there are more than 20 different diagram elements just for BDD's).
Figure 11 Meta-model block definition diagram
Concept Description
BLOCK DEFINITION DIAGRAM The diagram as a whole, it consist of 1 or more BLOCKS.
BLOCK
The main modular unit in a block definition diagram, a BLOCK has several specializations. Zero too many BLOCK have one to many ASSOCIATION. The only properties it has is Name.
UNIT BLOCK An UNIT BLOCK is a specialization of the BLOCK, it gives an identification of a physical quantity. It has the property QuantityKind.
VALUETYPE BLOCK
A VALUETYPE BLOCK is a specialization of the BLOCK, provides a uniform definition of quantity. It has the properties Values, Operations and ValueType
BASIC BLOCK
A BASIC BLOCK is a specialization of the BLOCK, it is the most basic version of the BLOCK with no special meaning. It has the properties Parts, References an Values
ENUMERATION BLOCK An ENUMERATION BLOCK is a specialization of the BLOCK, it gives a definition for a set of values. It has the property EnumerationLiteral
ACTOR BLOCK An ACTOR BLOCK is a specialization of the BLOCK, it indicates this block is an actor and has no special properties
ASSOCIATION
Set of lines used to create different kinds of relations between BLOCK's and the other concepts. Multiplicities at both ends can be used. Also an association can be given a name.
COMPOSITE A COMPOSITE ASSOCIATION is a whole-parts relation.
GENERALIZATION
A GENERALIZATION ASSOCIATION is a way to indicate a specialization of a certain concept. The arrow is pointing to the parent.
REFERENCE
A REFERENCE ASSOCIATION is used to create a basic relation between two concepts.
ONE-WAY REFERENCE
A ONE-WAY REFERENCE ASSOCIATION is used to create a basic relation between two concepts. Going only one way, a white diamond indicates which way.
TWO-WAY REFERENCE
A TWO-WAY REFERENCE ASSOCIATION is used to create a basic relation between two concepts going two ways.
Table 3 Concept table meta-model block definition diagram
Related literature The system modeling language (SysML) was created in January 2001 when the International Council on
Systems Engineering’s workgroup for Model Driven Systems Design decided to customize UML for
system engineering application (Object Management Group, 2016). When the decision was made they
worked together with the Object Management Group (OMG) to create the language. The Object
Management Group is still maintaining the SysML specification.
SysML can be used to model every system but in application, it mainly focusses on complex systems.
For example, SysML can be used to do a reliability study on a complex physical system as shown by
(David, Idasiak, & Kratz, 2010).
In the model-based engineering area, it has become common practice to use UML as a basic design
language, but because UML is too generic for certain domains different profiles for UML are being added
to the langue like SysML. Espinoza, Cancila, Selic, & Gerard (2009) have tried to combine two of these
profiles (SysML and MARTE) for an interdisciplinary field.
Also, there has been done research to combine SysML with the Modelica language to combine the
descriptive power of SysML and the analytic and computational power of Modelica (Peredis, et al., 2010)
A model-driven design approach is already been used by companies like Motorola for over 25 years, in
this approach, they make use of SysML to model their complex systems (Baker, Loh, & Weil, 2005).
Da Silva, Linhares, Padilha, Roqueiro, & Oliveira (2006) conclude trough an empirical case study where
an electronic fuel injection system was developed that SysML provides a good specification for an
embedded system. It can reduce documenting and communication problems among a team although a
good understanding of object-oriented modeling is required of every team member, this can present a
barrier.
Except for just designing new systems SysML can also successfully be used for product improvement or
design modification as shown by Hochwallner, Horl, Dierneder, & Scheidl (2011). In their research, they
apply SysML in their process of reverse a mechatronic system.
Although SysML has proven to be an effective modeling language for complex systems it cannot support
all model-based engineering activities (Kapos, Dalakas, Tsadimas, Nikolaidou, & Anagnostopoulos,
2014). SysML fails to easily accommodate system validation, SysML system models first have to be
transformed to domain-specific models before system validation can take place in specific simulation
tools.
Bone & Cloutier (2010) conclude from their survey about SysML in 2009 that largest inhibitor for
SysML adaptation is the large required learning curve. Respondents to the survey noted that the learning
curve is so large because you actually have to learn three different topics, first the SysML langue second
the methodology (which can differ per project) and third the tool. It also notes that the learning material
available is insufficient, it lacks real project examples and best practices.
References Baker, P., Loh, S., & Weil, F. (2005). Model-Driven Engineering in a Large Industrial Context —
Motorola Case Study. In Model Driven Engineering Languages and Systems, 376-291.
Bone, M., & Cloutier, R. (2010). The Current State of Model Based Systems Engineering: Results from
the OMG™ SysML Request for Information 2009. Proceedings of the 8th Conference on Systems
Engineering Research. Hoboken.
da Silva, A. J., Linhares, M. V., Padilha, R., Roqueiro, N., & Oliveira, R. S. (2006). An empirical study of
SysML in the modeling of embedded systems. SMC'2006 - IEEE International Conference on
Systems, Man and Cybernetics, (pp. 4569-4574). Taipei.
David, P., Idasiak, V., & Kratz, F. (2010). Reliability study of complex physical systems using SysML.
Reliability Engineering & System Safety, 431-450.
Espinoza, H., Cancila, D., Selic, B., & Gerard, S. (2009). Challenges in Combining SysML and MARTE
for Model-Based Design of Embedded Systems. Model Driven Architecture-Foundations and
Applications, 98-113.
Friedenthal, S., Moore, A., & Steiner, R. (2014). A Practical Guide to SysML: the systems modeling
language. Waltham: Morgan Kaufmann.
Hochwallner, M., Horl, M., Dierneder, S., & Scheidl, R. (2011). Some Aspects of SysML Application in
the Reverse Engineering of Mechatronic Systems. Computer Aided Systems Theory - EUROCAST
2011 (pp. 81-88). Spain: Springer.
Kapos, G.-D., Dalakas, V., Tsadimas, A., Nikolaidou, M., & Anagnostopoulos, D. (2014 ). Model-based
system engineering using SysML: Deriving executable simulation models with QVT. Systems
Conference (SysCon), 2014 8th annual IEEE (pp. 513-538). Ottawa: IEEE.
Object Management Group. (2016, February 18). Documents Associated With SysML. Retrieved from
Object Management Group: http://www.omg.org/spec/SysML/1.2/
Peredis, C. J., Bernard, Y., Burkhart, R. M., de Koning, H.-P., Friedenthal, S., Fritzson, P., . . . Schamai,
W. (2010). An Overview of the SysML-Modelica Transformation Specification. INCOSE
International Symposium, (pp. 709-722). Chicago.
Weerd, I. v., & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In
M. R. Syed, & S. N. Syed, Handbook of Research on Modern Systems Analysis and Design
Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing.