See discussions, stats, and author profiles for this publication at: [Link]

net/publication/228401777

Behavioral modeling in system engineering

Article · January 2011

CITATIONS READS

3 17,146

3 authors:

Radek Silhavy Petr Silhavy

Tomas Bata University in Zlín Tomas Bata University in Zlín
88 PUBLICATIONS 625 CITATIONS 65 PUBLICATIONS 573 CITATIONS

SEE PROFILE SEE PROFILE

Zdenka Prokopová
Tomas Bata University in Zlín
93 PUBLICATIONS 703 CITATIONS

SEE PROFILE

All content following this page was uploaded by Radek Silhavy on 26 May 2014.

The user has requested enhancement of the downloaded file.

 Recent Researches in Automatic Control

Behavioral Modeling in System Engineering

RADEK SILHAVY, PETR SILHAVY, ZDENKA PROKOPOVA
Department of Computer and Communication Systems
Faculty of Applied Informatics
Tomas Bata University in Zlin
nám. T. G. Masaryka 5555, 760 01 Zlín
Czech Republic
rsilhavy@[Link], psilhavy@[Link], prokopova@[Link] [Link]

Abstract: - This contribution focuses on the behavioral modeling of the systems in the system engineering. The
system engineering process is described and overview of the system modeling language (SysML) is presented.
The SysML basic principles and diagrams are discussed. Practical part of the paper discusses behavioral
modeling process, which is illustrated by the set of the example models.

Key-Words: - System engineering, system modeling, behavioral modeling, sysml, uml.

1 Introduction
The System engineering [1] is understood as
complex discipline for the system design and
analysis of the system. The system is for the purpose
of the system engineering defined as a set of the
components which are interconnected and provides
the group of emergent properties [1]. These
emergent properties are derivate from the properties
of the system components, but new dimension is
added by the system integration.
A system engineering processes are about
preparing [2] generic stakeholder goals,
requirements, system design, evaluation of
alternative system designs, allocation of functional
requirements, system verification. All of these
activities lead to creation of the balanced system.
The system development generic process is
described by waterfall model [1]. The process
should be composed of:
1) Requirements Engineering Definition and
Elicitation.
2) System Design.
3) Sub-system Development.
4) System Integration.
5) System Installation.
6) System Evolution.
7) System Decommissioning.
Fig 1: Waterfall Model of the System
Engineering

The system requirements engineering general

name for the specific sets of the software
engineering techniques, which is used at the

ISBN: 978-1-61804-004-6 100

 Recent Researches in Automatic Control

beginning of the software cycle. The purpose of The system design phase deals with association
these techniques is to discover stakeholder’s needs. of the system requirements to individual sub-
The requirements gathering process in system system, more specific to system components. The
engineering has these basics steps, which are set of the system requirements is studied and
graphically described on the next figure. individual requirement is associated to proposed
component. One of the most common techniques,
which could be applied in this process, is to sub-
system design first. Than system designers is able to
associated selected requirements to the specific
subsystem. The process of the sub-systems
identification and requirements association is
interactive and is commonly modeled in form of
spiral.
In the system modeling phase is a system
architecture designed. This activity is based on sub-
system (or component) design. The system is
modeled as group of interconnected blocks, where
connection indicates data flow or other form of
dependency. The main task is to create more
concrete definition of the sub-systems, which were
set-up in the system design phase.
The sub-system development phase works with
sub-system or system components implementation.
The sub-systems are implemented in parallel. This is
because of sub-systems in the system engineering is
not only hardware/software, but also should be
create by civil engineering.
Next step in the system engineering life-cycle is
the system integration. The implemented subsystem
are integrated into the system [1]. The integration is
Fig 2: Requirements Definition Model an incremental process. The sub-system are
integrated, when their implementation is finished.
The requirement [1] is a description of the This approach is time-less consuming, then legacy
functionality or condition which stakeholders define approach, when all components were implemented
for the system. After the first round of requirements together.
gathering is talked about the raw or abstract The system evolution and system decommission
requirements. These raw requirements are list of are the final phase of the system lifecycle. A system
functionality or condition for the proposed software, designer should care about system improvements
which is unanalyzed yet. The most important in this during its production time. They also should take
phase is to establish the project goals, which should care about times, when system should be prepared
be achieved. for out-of-service elaboration.
The next group of the requirements is non- The main task of the software engineering is a
functional requirements. The purpose of these system development from very beginning
requirements is familiarized system designers with (requirements elicitation) to system decommission.
problem domain and conditions in the domain.
Well-known examples of these are reliability,
performance, safety or security. These non-
functional requirements are critical in the system
2 Problem Formulation
In the system engineering lifecycle, which were
evaluation very often.
described above, basic ideas of the system
The last part of the requirements gathering is so-
engineering were concluded. In the system
called system characteristics. The system
engineering are used well-known techniques for
characteristics are commonly prepared in negative
modeling. Probably the most common is block
way. It means, that system design specifies what
diagramming. This model is used for system design
irrelevant system behavior is.
and for sub-system analyze. Secondly data flow

ISBN: 978-1-61804-004-6 101

 Recent Researches in Automatic Control

diagrams are common for definition of data and State machine diagram presents set of state of the
process designing. modeled entity and events which generated message
Today state-of-art in research of graphical upon which entity state is switched.
documentation of the system development is System Use Case diagram is used for the system function
Modeling Language (SysML). The SysML is a description. This model is composed of the actors,
graphical modeling language [2], which is derivate which are external entity and of the use cases. The
from Unified Modeling Language (UML). UML is use cases represent system functions or algorithms.
an industry standard in the scope of the software Each of the use case has to realize one of the
engineering. SysML is a extension of UML, this two requirements as minimum.
basic technique shared basic principles and some Block definition diagram is used instead of the
types of diagrams are used in both. The SysML take class model in UML. The purpose of the block
important role in the system engineering, because its definition is to model system structure.
usability in all phase of software engineering Internal block diagram is similar to UML
process. composite structure. The main idea of this diagram
is to model internal structure of the each individual
3 System Modeling Language part of the proposed block. Very important here is
SysML is relatively young modeling language. modeling of interface and communication between
Its history is written from 2001, when Systems block´s entities.
Engineering Domain Special Interest Group were Parametric diagram is SysML origin and have no
set-up [3]. Today, there is 1.2 version from 2010 predecessor in UML principles. Is used for
valid. modeling system parameters and constrains, should
be used for critical – hazard system states.
3.1 Language Overview Package diagram is useful for model organizing.
The modeling project support analysis, Model elements should clustered by its stereotypes.
specification, design, verification and validation of Packages also should be used for creation of a large
systems. SysML therefore support all phases of the project structure.
system engineering lifecycle.
The system components should be described by 4 Behavioral Modeling Process
structural composition, interconnection and In this chapter will be introduced sample
classification. Secondly by function-based approach projects, which contains example model of each
which is based on messages between objects. This type of the diagrams. For purpose of this article
aspect should respect to constrains, which are authors adopted project which was prepared by
derived from physical system structure or from SparxSystems as sample project in SysML language
performance properties. Important role takes [4].
association of system functionality to each of the In this sample is described development of the
system components. audioPlayer. The main task of the project team was
In the SysML nine of diagrams are of recognized to offer a solution which was successfully in
[2]. usability and which offers appropriate functionality.
Requirements diagram is used for graphical For purpose of this description authors used
interpretation of requirements and their connection modified version of behavioral modeling process
to other requirements and to other elements and [4].
entities in project – such test cases, use cases. For
those how are familiars to UML, this diagram is
new in SysML and have never be used in UML.
Activity diagram is based on UML activity
diagram; there is slightly different usage of it.
Basically is used for modeling of flows of actions
based on the availability of inputs, outputs or
control. Transformation of actions is also modeled
by activity diagram in SysML.
Sequence diagram is used for representing of
message flow between objects.

ISBN: 978-1-61804-004-6 102

 Recent Researches in Automatic Control

customSpecifications

Specifications

«requireme...
User
Friendliness «requireme...
Durability

«requireme...
Keys Layout
«requireme...
Weather
resistance

«requireme...
Graphical User
interface «requireme...
Shock
Resistance

«requireme...
Scroller

«requireme...
Performance
«requireme...
Media Access

«requireme...
Fidelity
«requireme...
External ports

«requireme...
Battery
«requirement»
longevity
Storage
Capacity

«requireme...
Noise
Reduction

Fig 4: Requirements Model

The user friendliness group defines set of the

requirements, which deal with quality of service of
the audio player. Keys Layout, Graphical User
Interface and Scroller are primary requirements,
Fig 3: Behavioral Modeling Process which take important role in user satisfaction.
When the requirements model is finished, next
The behavioral modeling is a description (Figure step is use case model. In the use case model there is
3) how the proposed system will interact with the an algorithmic definition of the actors’ activity in
actors and with entitles which is out of boundary of the system. In the figure system boundary, actor and
the system. use cases can be seen. The boundary is named as
The first step in the creation of the system Playlist Maintenance, because this model describes
behavioral model is the requirements gathering. only activities of the listener, which are available as
In the figure can be seen model of the maintain the playlist. Inside of the each individual
requirements. The diagram illustrates hierarchical use case is scenario description. The scenario is a
structure of the requirements. On the top of the tree sequence of steps, which describes a track, should
the Specification package can be seen. Other parts be downloaded. In this Use Case model include
are interconnected by containment association. The association is used. The “include” association is
specification is clustered into sever groups. Groups used for situation, when the use case contains other
are User Friendliness, Durability, Performance and use case for achieving its goal.
Media Capacity.

ISBN: 978-1-61804-004-6 103

 Recent Researches in Automatic Control

sd Maintain Playl...

uc Maintain Playl... Maintain Playlist - Use Case

deviceInContext
Playlist Maintenance :Portable Audio
Player
listener :Listener

Maintain Playlist (Interaction)

ref
Connect To Computer ConnectToComputer

ref
CopyTracks

Copy track from ref

DownloadTracks
external media

ref
ViewExistingPlaylists

Listener
alt
Download track [playlistsExists]
ref
ViewNewTracks

View Existing Playlist alt

[playlistEditable]

«include» ref
ModifyPlaylist
Create Playlist

ref
«include» CreatePlaylist

View New Tracks

Fig 6: Sequence Diagram for Playlist

Fig 5: Use Case Model Maintaining

The Use Case models (Figure. 5) are derivate The last view of the system can be done by state
from requirements. The Use Cases are commonly machine diagram. The most important noticeable
prepared for individual system blocks. This is fact here is, that by state machine diagram is
rigorous connection between the requirement and modeled same system in the different view only.
the use case. This connection should be modeled as The Figure 8 shows modified version of the state
realization in the use case model or can be machine diagram. It does not present only two basic
documented in form of the responsibility matrix. states – idle and connected. The state connected is
The interaction in form of sequence diagram is describes in form of the activity diagram. In the
useful for modeling overview of operations. In the connected state tracks could be copied and
Fig 7 can be seen overview of diagram, which downloaded. These two operations are in a parallel
describes all possible activity of the actor, called section, which is created by using fork/join artifacts.
Listener. There are used fragments, which used for
referencing individual activity descriptions. These
are named as ref. The alt abbreviation is used for
conditions. In this context the viewnewtracks can be
executed only if the playlist exists.

ISBN: 978-1-61804-004-6 104

 Recent Researches in Automatic Control

stmPlaylist Maintenan... The system behavioral modeling deals with

Idle requirements engineering, use cases elicitation and
state modeling of the system.
[disconnect]
Further research in system modeling is focused
[connect]
on the improvement of the simulation environment
and to the model based development, which
stmConnected probably the most important in the development of
the system engineering.
[loadNewTracks]
Acknowledgments
This work was supported by the Ministry of
Education, Youth and Sports of the Czech Republic
under the Research Plan No. MSM 7088352102.
Copy Tracks Download Tracks

References:
[1] SOMMERVILLE, Ian. Software Engineering.
Eight Edition. Harlow : Pearson Education
[retrieve] Limited, 2007. 824 s. ISBN 978-0-321-31379-9.
[2] FRIENDENTHAL, Sanford; MOORE, Alan;
View Playlists STEINER, Rick. A Practical Guide to SysML :
The Systems Modeling Language. USA :
Morgan Kaufmann, 2009. 5769 s. ISBN 978-
0123786074.
[modifyplaylist]
[3] Object Management Group. Systems
[createplaylist]
Engineering Domain Special Interest Group
[online]. 2007-2011 [cit. 2011-03-20]. Available
View NewTracks
on WWW: <[Link]
[4] ROSENBERG, Doug; MANCARELLA, Sam.
Create Playlist Embedded Systems Development using SysML.
[s.l.] : Sparx Systems Ply Ltd, ICONIYX, 2010.
Modify Playlist 68 s.

Fig 7: State Machine Diagram with Activity

4 Conclusion
The idea of the contribution was to introduce
System Modeling Language for modeling system
behavior. The system engineering were described
and connection between system modeling language
diagrams and the system engineering phases were
illustrated.
For the example purpose part of the the audio
player model were presented.
The modeling project support analysis,
specification, design, verification and validation of
systems. SysML therefore support all phases of the
system engineering lifecycle.
The SysML uses number of diagram, which
allow to a system designer model the proposed
system in many views.

ISBN: 978-1-61804-004-6 105

View publication stats