Block definition diagrams in the Systems Modeling …5676932/me/AssignmentD_4004736_Jan… · Block definition diagrams in the Systems Modeling Language (SysML) Student: ... activity,

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.