Synthesis of Extended Hierarchical Real

Transcription

Synthesis of Extended
Hierarchical Real-Time Behavior
by
Sebastian Franz Goschin
Faculty for Electrical Engineering, Computer Science und Mathematics
Department of Computer Science, Heinz Nixdorf Institute
Research Group Software Engineering
Zukunftsmeile 1
D-33102 Paderborn
Synthesis of Extended
Hierarchical Real-Time
Behavior
Master’s Thesis
within the Course of Studies in Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Science
by
Sebastian Franz Goschin
Alte Brauerei 27
33098 Paderborn
advised by
Stefan Dziwok
submitted to
Prof. Dr. Wilhelm Schäfer
and
Prof. Dr. Gregor Engels
Paderborn, February 2014
Declaration
(Translation from German)
I hereby declare that I prepared this thesis entirely on my own and have not used
outside sources without declaration in the text. Any concepts or quotations applicable to these sources are clearly attributed to them. This thesis has not been
submitted in the same or substantially similar version, not even in part, to any other
authority for grading and has not been published elsewhere.
Original Declaration Text in German:
Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser
als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen, die
wörtlich oder sinngemäß übernommen worden sind, sind als solche gekennzeichnet.
City, Date
Signature
v
Contents
1 Introduction
1.1 Problem . . . . . . .
1.2 Goal . . . . . . . . .
1.3 Approach . . . . . .
1.4 Document Structure
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
5
6
8
2 Fundamentals
2.1 Model-Driven Software Development . . . .
2.2 Development of Domain-Specific Languages
2.3 Textual Languages . . . . . . . . . . . . . .
2.4 Model Transformation . . . . . . . . . . . .
2.5 Timed Automaton . . . . . . . . . . . . . .
2.6 Formal Verification . . . . . . . . . . . . . .
2.6.1 Formal Properties . . . . . . . . . . .
2.6.2 Model Checking . . . . . . . . . . . .
2.6.3 Refinement Check . . . . . . . . . . .
2.7 Compositional Verification Approach . . . .
2.8 MechatronicUML . . . . . . . . . . . . .
2.8.1 Structure . . . . . . . . . . . . . . .
2.8.2 Behavior . . . . . . . . . . . . . . . .
2.8.3 Development Process . . . . . . . . .
2.8.4 Demarcation to MDSD and DSL . .
2.9 GQM - Goal Question Metric . . . . . . . .
2.9.1 GQM Process . . . . . . . . . . . . .
2.9.2 GQM Model . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
12
13
14
15
16
16
17
18
20
20
22
25
25
26
27
27
3 Synthesis Method for Extended Hierarchical Real-Time Behavior
3.1 Requirements of Synthesis Method . . . . . . . . . . . . . . . .
3.1.1 Requirements for Development Method and its Process .
3.1.2 Requirements: Dependency Language . . . . . . . . . . .
3.1.3 Requirements: Synthesis Algorithm . . . . . . . . . . . .
3.2 Synthesis Method Application Procedure . . . . . . . . . . . . .
3.2.1 Step 1: Method Analysis . . . . . . . . . . . . . . . . . .
3.2.2 Step 2: Method’s Process Adaptation . . . . . . . . . . .
3.2.3 Step 3: Dependency Kind Analysis . . . . . . . . . . . .
3.2.4 Step 4: Dependency Language Development . . . . . . .
3.2.5 Step 5: Conflict Analysis Algorithm Development . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
31
31
32
33
33
34
34
35
35
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
Contents
3.2.6
Step 6: Automatic Synthesis Algorithm Development . . . . . 36
4 Application to MechatronicUML
4.1 Step 1: Method Analysis . . . . . . . . . . . . . . . . . . .
4.1.1 MechatronicUML’s Situation before this Thesis
4.1.2 Application Challenges . . . . . . . . . . . . . . . .
4.2 Step 2: Process Adaptation . . . . . . . . . . . . . . . . .
4.3 Step 3: Dependency Kind Analysis . . . . . . . . . . . . .
4.3.1 Requirements for Dependencies . . . . . . . . . . .
4.3.2 Catalog of MUML’s Dependency Kinds . . . . . . .
4.3.3 Categorization of Depedency Kinds . . . . . . . . .
4.3.4 Combinations of Dependencies . . . . . . . . . . . .
4.3.5 Running Example: Dependency Analysis of Track .
4.3.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . .
4.3.7 Summary and Discussion of Step 3 . . . . . . . . .
4.4 Step 4: Dependency Language Development . . . . . . . .
4.4.1 Discussion of Existing Languages . . . . . . . . . .
4.4.2 Domain . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 Stakeholder, Viewpoint and View . . . . . . . . . .
4.4.4 Syntax and Semantics . . . . . . . . . . . . . . . .
4.4.5 Running Example: Dependency Model of Track . .
4.4.6 Technical Integration into existing MUML Tooling .
4.5 Step 6: Synthesis Algorithm . . . . . . . . . . . . . . . . .
4.5.1 Synthesis Algorithm Process . . . . . . . . . . . . .
4.5.2 Implementation Details . . . . . . . . . . . . . . . .
4.5.3 Running Example: Synthesis of Sections . . . . . .
5 Related Work
5.1 MechatronicUML’s Old Synthesis Approach
5.1.1 Composition Rules . . . . . . . . . . . .
5.1.2 Synthesis Process . . . . . . . . . . . . .
5.1.3 Demarcation . . . . . . . . . . . . . . . .
5.2 Other Component Behavior Syntheses . . . . .
5.2.1 Synthesis from partial behavior models .
5.2.2 Synthesis from Properties . . . . . . . .
5.2.3 Synthesis from Scenarios and Properties
5.3 Model-based Behavioral Dependency Analysis .
5.4 Synthesis of Component-based Systems . . . . .
5.5 Related MDSD approaches . . . . . . . . . . . .
5.5.1 SOFA 2 . . . . . . . . . . . . . . . . . .
5.5.2 Cadena . . . . . . . . . . . . . . . . . .
5.5.3 COMDES-II . . . . . . . . . . . . . . . .
5.6 Software Patterns . . . . . . . . . . . . . . . . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
40
44
47
51
51
52
56
58
59
61
69
70
70
71
72
72
83
83
85
87
87
88
90
90
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
94
96
97
98
98
99
100
100
101
101
101
102
103
105
Contents
6 Conclusion
107
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Bibliography
111
Appendix
A Running Example
A.1 Structure Definition . . . . . .
A.2 Behavior Definition . . . . . .
A.2.1 Protocol . . . . . . . .
A.2.2 Normal Track Section .
A.2.3 Crossing . . . . . . . .
A.2.4 Switch . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
. 119
. 121
. 121
. 123
. 126
. 132
B Catalog of Dependency Kind
(1) Synchronization . . . . . . . . . . . . .
(2) Event Constraint . . . . . . . . . . . .
(2a) Required State Constraint . . . . . .
(2b) Once Required State Constraint . . .
(2c) Required Transition Constraint . . . .
(2d) Once Required Transition Constraint
(3) Message Sequence Constraint . . . . .
(4) Entry-/ Exit-Clock Constraint . . . . .
(5) Access-/ Leave-Counter Limitation . .
(6a) Forbidden State Combination . . . .
(6b) Allowed State Combination . . . . . .
(7a) Forbidden Message Sequence . . . . .
(7b) Allowed Message Sequence . . . . . .
(8) Bounded Active State . . . . . . . . .
(9) Data Merge . . . . . . . . . . . . . . .
(10a) Data Pull . . . . . . . . . . . . . . .
(10b) Data Push . . . . . . . . . . . . . .
(11) Data Constraint . . . . . . . . . . . .
(12) Clock Merge . . . . . . . . . . . . . .
(13) Clock Reset . . . . . . . . . . . . . .
(14) Clock Constraint . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
139
140
140
142
142
143
145
145
147
147
148
149
150
152
153
153
154
156
156
158
158
159
C Survey Material
161
C.1 Offline Version of the Survey . . . . . . . . . . . . . . . . . . . . . . . 161
C.2 Detailed Summary of the Results . . . . . . . . . . . . . . . . . . . . 161
D Implementation Details
163
D.1 Dependency Language . . . . . . . . . . . . . . . . . . . . . . . . . . 163
ix
Contents
D.1.1 Meta Model . . . . . . . . . . . . . . . . . . . .
D.1.2 XText Grammar . . . . . . . . . . . . . . . . .
D.1.3 Technical Details . . . . . . . . . . . . . . . . .
D.2 Synthesis Algorithm: QVT-O Transformation . . . . .
D.2.1 RTSC Copy Library . . . . . . . . . . . . . . .
D.2.2 Synthesis Transformation . . . . . . . . . . . . .
D.2.3 Step 1: Port Behavior Copy Transformation . .
D.2.4 Step 2: Dependency Integration Transformation
E CD Content
x
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
164
166
174
175
175
175
175
175
177
List of Figures
1.1
1.2
1.3
1.4
Railcab Scenario [HBDS14, cf.] . . . . . . . . . . . . . . .
Inter- vs. Intra-Behavior . . . . . . . . . . . . . . . . . . .
Separation of Behavior in MechatronicUML . . . . . .
Abstraction of Component Behavior Development Process
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
3
6
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Concrete Syntaxes: (a) Graphical and (b) Textual . . .
Syntax of Timed Automata Network . . . . . . . . . .
TCTL Property Example . . . . . . . . . . . . . . . . .
Refinement of the left Timed Automaton of Figure 2.2
Development Steps of Compositional Verification . . .
Syntax of MechatronicUML’s Component . . . . .
Examplary Component Instance Configuration . . . . .
Syntax of Real-Time Coordination Protocol . . . . . .
Syntax of Real-Time Statechart . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
15
16
17
18
21
21
22
23
3.1
Procedure to Apply the Synthesis Method . . . . . . . . . . . . . . . 34
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
Applied Parts of the general Procedure . . . . . . . . . . . . . . . . .
The Subprocess to model the Behavior of a Component [BBB+ 12, p.93]
Dependency between the Switch’s Ports . . . . . . . . . . . . . . . . .
Modified Subprocess to model Component’s Behavior [BBB+ 12, cf.
p.93] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Synthesis of Enforced Transition Combination . . . . . . . .
Example Synthesis of Required Change Event Constraint . . . . . . .
Example Synthesis of State Space Limitation . . . . . . . . . . . . . .
Example Synthesis of Data Assignment . . . . . . . . . . . . . . . . .
Example Synthesis of Data Constraint . . . . . . . . . . . . . . . . .
Component Behavior of Normal Track Section . . . . . . . . . . . . .
Event Constrained Interval Conditions’ Evaluation Examples . . . . .
Component Diagram Editor’s Property Extensions Tab . . . . . . . .
Atomic Component’s Right-Click Menu. . . . . . . . . . . . . . . . .
Dependency Language Editor surround by Real-Time Statecharts . .
Process of the Synthesis Algorithm . . . . . . . . . . . . . . . . . . .
5.1
5.2
Event Composition Automaton eca1 [Eck09, p.58] . . . . . . . . . . . 95
Hierarchical architecture model of a Comdes-ii system [KSA07, p.3] 104
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
41
43
47
53
54
55
55
56
60
77
84
84
85
88
A.1 Railcab Scenario [HBDS14, cf.] . . . . . . . . . . . . . . . . . . . . . 119
A.2 Component Types of the Running Example . . . . . . . . . . . . . . 120
xi
List of Figures
A.3 Component Instance Configuration conform to Scenario
A.4 Next Section Protocol’s Roles . . . . . . . . . . . . . .
A.5 Enter Section Protocol’s Roles . . . . . . . . . . . . . .
A.6 Behavior of Normal Track Section’s left and right port
A.7 Inner-Behavior of Normal Track Section . . . . . . . .
A.8 Normal Track Sections Component’s Behavior . . . . .
A.9 Left Port’s Behavior of Crossing . . . . . . . . . . . . .
A.10 Right Port’s Behavior of Crossing . . . . . . . . . . . .
A.11 Inner-Behavior of Crossing . . . . . . . . . . . . . . . .
A.12 Crossing Component’s Behavior . . . . . . . . . . . . .
A.13 Crossing Component’s Behavior Zoom Part 1 of 2 . . .
A.14 Crossing Component’s Behavior Zoom Part 2 of 2 . . .
A.15 followingSection Ports’ Behavior of Switch . . . . . . .
A.16 Left / Bottom / Right Port’s Behavior of Switch . . . .
A.17 Inner-Behavior of Switch . . . . . . . . . . . . . . . . .
A.18 Switch Component’s Behavior . . . . . . . . . . . . . .
A.19 Switch Component’s Behavior Zoom Part 1 of 3 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
120
121
122
123
123
125
126
127
127
129
130
131
132
133
133
135
136
137
138
D.1 Meta Model of Dependency Language . . . . . . . . . . . . . . . . . . 165
xii
1 Introduction
Transportation vehicles such as cars, trains, and airplanes are referred to as mechatronic systems [Bol04]. Their software ratio is growing [BKPS07] because they are
increasingly extended by software features every day, e.g., navigation, parking assistance, and speed control. To enable those features, they contain mechanical,
electrical, control, and software components. One important challenge is handling
the increasing complexity of software development. This thesis, which focuses on
behavioral software development, contributes to solving this problem.
One goal in the transportation field is the development of autonomously driving vehicles. These may contain processing units, wireless communication modules, distance
sensors, cameras, positioning systems, etc., and their primary control accomplishes
software. The software’s architecture can be component-based; each of its components can have their own behavior. Thus, the system’s behavior is determined
through the composition and connection of its components. In such autonomous systems, an important aspect is safety-criticality. Hence, their behavior must satisfy
strict requirements.
The thesis illustrates its approach using an advanced railroad system [NBP] (see
Figure 1.1) which enables autonomously driving trains (RailCabs). These trains
have to operate according to certain traffic rules. For example, RailCabs are not
allowed to enter a railroad track section without permission. To gain permission,
they must coordinate with other trains and track control systems using messagebased communication. This coordination 1 must ensure strict observance of the traffic
1
The communication on OSI Layer 7 or between two systems on OSI Layer 7 [ISO94].
Normal Track
Section (ts1)
Switch (ts3)
Railroad
Crossing (ts4)
RailCab 1
RailCab 2
Normal Track
Section (ts2)
φ: at most one
RailCab on a section
ψ: following section is free
Figure 1.1: Railcab Scenario [HBDS14, cf.]
1
1. Introduction
rules. It is important that all components (trains and tracks) are in compliance. If a
component disregards a rule, it could precipitate a life-threatening situation, e.g., a
collision. In Figure 1.1, the Switch coordinates with both approaching RailCabs and
the following track section (Railroad Crossing). Coordinating the Switch requires
that it only been used by one RailCab at a time (requirement ϕ from Figure 1.1) and
that the following section is free (requirement Ψ ). These requirements are safetycritical and describe dependencies between the different coordinations of Sections
and RailCabs.
The aforementioned example is simple, but they can be more complex. For example, the coordination could involve more components. Further, the components’
behavior could contain data, operations, real-time requirements, concurrency, hierarchy, etc. To manage such extended hierarchical real-time behavior specifications,
the developer requires a separation of concerns, especially with respect to safety.
One possibility is a separation of inter-behavior (coordination protocols) from intrabehavior specification (component behavior). It is illustrated in Figure 1.2. The
inter-behavior (yellow) specifies external visible behavior between connected components. It describes all message sequences that are allowed between components
and so determines how component ports must behave. Furthermore, its specification can contain timing requirements, e.g., a response must be received within
10 seconds. The intra-behavior (blue) specifies the component’s behavior. It determines how inner-behavior (orange) and the ports’ behaviors are connected. It
models dependencies (red arrows) such as like data transport, messages sequences,
and required states between its different ports. However, both behaviors overlap at
the ports (green) which should illustrate that intra-behavior has to comply to the
inter-behavior.
InterBehavior
Green
Orange
Yellow
Blue
Dependencies
InnerBehavior
Intra-Behavior
Figure 1.2: Inter- vs. Intra-Behavior
This kind of separation of concerns has several motivations. It provides a better modularity that improves the maintainability and re-usability of a software system and
its components. As such, it enables the handling of complex coordination scenarios.
It further makes large systems2 verifiable through timed model checking [BK08]. In
particular, it allows separate verification of protocols3 and components’ behaviors.
2
3
2
Large system: 100 million lines of codes, hundreds of components. [Cha09]
In some literature, the protocols are called contracts. [GV06]
Afterwards, it is sufficient for the verification to prove that the components’ behaviors comply with their protocols, e.g., via refinement checking [BHSH13]. This
was shown by Giese [Gie03, GS12] with his compositional verification approach.
Thus, the separation circumvents the typical verification problem of “state explosion” [CKNZ12] which occurs when behavior gets too complex.
However, such separation of behavior also brings disadvantages. It causes additional
effort during the behavior development. A specification of protocols is superfluous
for a small system. Furthermore, it intentionally ignores dependencies to make the
initial development simpler and splittable. This, however, requires that the behaviorally separated modules are reintegrated (synthesis). Therefore, the behavior engineer must synthesize – often manually – the set of inter-behaviors, inner-behavior,
and dependencies of the component, a non-trivial task. While synthesizing, he must
preserve all verified properties of each protocol while weaving the dependencies into
it. This is already challenging, but the task’s complexity can further grow exponentially through the number of involved inter-behaviors and dependencies. As such,
this task requires that the development process and language (method) provides
adequate support.
One domain-specific method that applies the separation of inter-behavior and intrabehavior is MechatronicUML [BBB+ 12], which is designed to specify the software
development of mechatronic systems. It is based on UML [UML11] but contains
significant changes, e.g., support for specification of extended hierarchical real-time
behavior and reconfigurations. It applies the approach of Giese [Gie03] and allows
component-wise modeling and analysis of a mechatronic system’s software. Its components are connected by ports and its behavior split as shown in Figure 1.3. Each
port behavior must refine its protocol’s role. The intra-behavior consists of its orthogonal ports’ behaviors, inner-behavior, and dependencies. Both behavior parts
ProtocolName
role1
role2
1. Protocol
(inter-behavior)
in
re f
es
messages
data
data
2. Component Behavior
(intra-behavior)
Figure 1.3: Separation of Behavior in MechatronicUML
are modeled using Real-Time Statecharts4 , which are basically a combination of
UML State Machines [UML11] and Uppaal Timed Automata [BY04]. Real-Time
Statecharts allow specification of synchronizations, asynchronous messages, data
assignments, hierarchies, timing constraints, etc. MechatronicUML’s process already proposes to synthesize automatically and manually. At present, the synthesis
is mostly manual.
4
One possible formalism to model extended hierarchical real-time behavior.
3
1. Introduction
1.1 Problem
The manual synthesis of software component behavior from separated protocols and
informal dependencies has several downsides: First, dependencies might be in conflict, e.g, mutually exclusive. This possibility should be detected as early as possible.
However, the first formal manifestation of dependencies is inside the intra-behavior.
As a result, the first possibility to identify them is during the manual modeling.
In addition, the synthesis’ complexity often correlates with the size of the interbehavior specifications, increasing with respect to the number of inter-behaviors
and dependencies. Furthermore, the complexity increases when a larger amount of
different dependencies kinds is used. Additionally, the specification of a dependency
is typically distributed over several locations inside a model. Both complexity and
distribution allow manual synthesis to become error-prone and render difficult the
ability to trace whether every requirement has been specified. This traceability can
get even worse through the fact that a manual specification does not ensure that a
dependency is always modeled the same. When real-time and safety requirements
are among the specification that must be preserved, the already heavy demands on
manual adaptation grow even more challenging. All previously mentioned problems
make an automatic synthesis preferable, because most of the problems could be
solved once and for all by developing a synthesis algorithm.
Currently, no general method for such an automatic synthesis exits. For example, in
the SOFA [MHB13] method, the intra-behavior is still considered a black-box and its
dependency specifications, such as data and control flow, are open issues [Mal12, cf.
p.122]. The MechatronicUML method already considers the automatic synthesis
within its process [BBB+ 12, cf. p.93], however there is no working implementation,
and its process does not allow specification of all dependencies because its activity
order is not optimal. Furthermore, it does not consider conflicts and synthesis
errors. Additionally, it remains unclear how requirements are mapped to behavior
development. Lastly, the process has not been evaluated in terms of usability and
safety properties. Thus, missing is a general method that specifies how an automatic
synthesis should be embedded and how the synthesis method should be applied.
There do exist several automatic synthesis algorithms that synthesize inter-behaviors
to intra-behavior. For example, Eckardt and Henkler [EH10] developed a synthesis
for Timed Automata, which uses a specific dependency language5 . Unfortunately,
their algorithm and dependency language lack some important features, such as the
abilities to synthesize and express data dependencies. Henkler [Hen12] adapted their
synthesis by substituting syntax elements of Timed Automata with semantically
equivalent elements of Real-Time Statecharts, though he did not extend it to the
full expressiveness of Real-Time Statecharts. To be specific, he neither included any
new dependencies nor extended the possible synthesis’ inputs. His thesis reduced the
Real-Time Statechart specification, e.g., such that it does not contain data. Thus, it
remains unclear as to what happens with data variables specified in inter-behaviors
5
4
They call it composition rules.
1.2 Goal
and data dependencies specifiable in intra-behavior. Therefore, Henkler’s approach
is no complete solution for MechatronicUML. Other approaches, like Uchitel et
al. [UBC07] and Koskimies and Mäkinen [KM94] are complete in their specification
of dependencies. However, those approaches are specified for very limited statebased intra-behaviors, which do not consider time, data, hierarchy, or concurrency.
In summary, there is currently no dependency language, synthesis algorithm, and
synthesis method that allows synthesizing extended hierarchical real-time behavior. The current work attempts to address these problems which is elaborated in
Section 1.2.
1.2 Goal
The goal of this thesis is a synthesis method for intra-behavior development. The
synthesis method shall ...
... allow the specification of dependencies between previously independent behaviors. This would be a dependency language that allows referencing elements
of inter-behaviors and inner-behavior. The dependency model shall increase
traceability of requirements and modularity, which implies improvement of reusability. A further advantage of the explicit modeling shall be that it enables
identification of conflicting dependencies earlier in the process. Ideally, those
conflicts are found before the synthesis, but the process must identify them no
later than directly post-synthesis. Otherwise, the conflicts would lead to an
invalid system.
... offer a synthesis algorithm that uses the explicit dependencies and independent
inter-behaviors to synthesize an intra-behavior, which enables tracing of all requirements and inter-behaviors. The synthesized intra-behavior must include
restrictions and synchronizations to obey the dependencies, but still preserve
verified properties of previously independent behaviors.
... include an improved process that defines how to integrate its dependency specification and synthesis algorithm in an existing development method. The
enhanced component’s behavior development process shall consider conflicts,
the activity order, verification, and debugging. In particular, the method’s
goal is to reduce software behavior’s development time and improve comprehension, maintainability, traceability, re-usability, and verifiability.
... concentrate on extended hierarchical real-time state-based behavior. It shall
be applied to MechatronicUML. This shall show the synthesis method’s
applicability and shall improve MechatronicUML’s development language
and process.
The thesis shall further provide a description of how the synthesis method can be applied independently of MechatronicUML such that other development methods
could make use of the synthesis method.
5
1. Introduction
To limit the scope of the thesis, the synthesis algorithm shall only support a subset
of dependency kinds expressible by the new dependency language. Additionally,
the synthesis algorithm does not guarantee an optimal solution. Also, the conflict
analysis of dependencies shall not be part of this thesis. Besides, the thesis ignores
reconfigurations of Real-Time Statecharts and shall not support MechatronicUML’s concept of multi-ports.
1.3 Approach
My approach aims to support various software development methods to integrate
an automatic synthesis in their behavior specification. The software development
methods must therefore support the separation of inter- and intra-behavior.
The synthesis method can be integrated as the development process in Figure 1.4
shows. It illustrates all activities6 required to develop a verified intra-behavior
from separated inter-behaviors. The development process begins with requirements,
which the protocol engineer uses to specify and verify the inter-behavior. In parallel, the components’ behavior engineer specifies inner-behavior. Afterwards, the
components’ behavior engineer models dependencies between inter-behaviors and
inner-behavior.
registrar
registered
clock: ca;
rear
Requirements
1
Inter-Behaviors
Specification
Inner-Behavior
Specification
register /
noPlatoon
front
unregistered
[cf > 999]
noPlatoon
unregister
/
platoonProposal
/
default
default
platoonProposal /
/ breakPlatoon
/ breakPlatoon
[cf > 999]
Dependencies
Specification
entry
platoonProposal
/ / {reset: cf}
waiting
[cf <= 999]
ca ≤ 500
/ startPlatoon
entry / {reset: ca}
platoonProposal /
platoon
[cf <= 999]
/ startPlatoon
platoon
Inter- & InnerBehaviors
Verification
not((unregistered, true)
AND ((waiting; cr > 250)
OR (convoy; true)))
clock: cf;
default
ca ≤ 2000
entry / {reset: ca}
clock: cf;
wait
requestUpdate /
cf ≤ 1000
entry / {reset: cf}
wait / performUpdate
cf ≤ 1000
2
Dependency
Model
Conflict Analysis
ComponentBehavior
noPlatoon
default
ComponentBehavior
noPlatoon
clock: cf;
Sync!
[cf > 999]
wait
cf ≤ 1000
entry / {reset: cf}
platoonProposal /
platoonProposal /
default
[cf <= 500]
/ breakPlatoon
platoon
«optional»
Manual Adaptation
clock: ce;
/ register
Synthesis Algorithm
unregistered
Sync?
/ unregister
default
ce ≤ 2000
entry / {reset: ce}
/ requestUpdate
performUpdate /
waiting
ce ≤ 500
entry / {reset: ce}
3
Intra-Behavior
Refinement Check
Legend
artefact
4
process step
Refinement Check
clock: cf;
Sync!
[cf > 999]
wait
cf ≤ 1000
entry / {reset: cf}
platoonProposal /
platoonProposal /
[cf <= 500]
/ breakPlatoon
/ startPlatoon
registered
platoon
/ startPlatoon
registered
clock: ce;
/ register
unregistered
Sync?
/ unregister
default
ce ≤ 2000
entry / {reset: ce}
/ requestUpdate
performUpdate /
waiting
ce ≤ 500
entry / {reset: ce}
Intra-Behavior
integrated analysis step
Figure 1.4: Abstraction of Component Behavior Development Process
In the third step, a synthesis algorithm generates the intra-behavior using interbehaviors, inner-behavior, and dependencies. The resulting intra-behavior shall
contain separated compartments for each inter-behavior, such that traceability and
maintainability is preserved. This is followed by the fourth step, a manual adaptation of the intra-behavior. An analysis step integrated in every step ensures a
verified intra-behavior and further enables error detection at the earliest possible
stage in the process.
6
6
Iterations are always possible but hidden for simplicity.
1.3 Approach
Through the optional fourth step, the synthesis method remains applicable even
in case of an incomplete dependency language or synthesis algorithm. This allows
increased focus on common dependencies, by which the development of a dependency
language and synthesis algorithm can be simplified and most intra-behaviors can still
be fully automatically synthesized.
How the synthesis method can be applied, depends on the software component development method. The application may require an adaptation of the development
method’s process. Therefore, the current process will be evaluated and, if necessary,
adapted such that it adheres to the previously described order. Further, the newly
introduced second and third process step depend on the target language. Thus,
we must develop the dependency language and synthesis algorithm language specifically. This thesis proposes the following procedure to integrate the synthesis method
with an existing development method:
At first, the method developer must extract possible dependencies from existing
intra-behaviors of the specific language. Therefore, he must identify language elements that can influence multiple inter-behaviors. These can be shared data, synchronous and asynchronous messages, etc. He can use the extracted dependencies
to categorize reoccurring dependency kinds. Afterwards, those kinds shall undergo
a detailed evaluation to ensure that all common dependency kinds have been identified. The result should provide an ordered list of dependency kinds, which enables
reasoning about what the specific dependency language is capable of expressing. The
thesis’s catalog of dependency kinds discovered during the integration into MechatronicUML shall serve others as an additional guide to possible dependencies.
Keep in mind that the catalog does not aim for completeness, but for common
dependencies to ease the dependency language and the synthesis algorithm.
Secondly, the developer must create a dependency language that supports all common dependency kinds. For the language’s syntax, existing languages can serve as
inspiration. The language shall provide a mostly comprehensible and intuitive language for all stakeholders (behavior, safety, and requirement engineer, and client).
Therefore, the thesis uses a textual representation that uses expressive keywords
instead of mathematical symbols. This might also be the simplest implementation
and shall enable comparison of dependencies and requirements that are specified in
natural language. However, the method developer could use another syntax. The
language allows only specification of common dependencies, because rare dependencies would unnecessarily increase its complexity.
Thirdly, the method developer must create the synthesis algorithm that uses intrabehaviors, the inner-behavior, and the model of the newly developed dependency
language as input. The thesis assumes that the dependencies can be independently
applied to the intra-behavior as long as they are conflict free.7 This being the case,
the method developer can use an incremental model transformation technique to
synthesize. Whether an incremental and independent transformation is always possible remains an unanswered question to be analyzed in future work. Moreover, this
7
This assumption must be confirmed in future work.
7
1. Introduction
can strongly depend on the development method with which the synthesis algorithm
is integrated.
The thesis applies the previous procedure onto MechatronicUML. This proceeds
as follows: First, the thesis analyzes dependencies that can be specified between different regions of one Real-Time Statechart. In doing so, it makes use of my personal
experiences and existing Real-Time Statechart models, e.g., the RailCab example of
Figure 1.1, to identify possible dependency kinds. The resulting dependency kind
catalog is evaluated using a survey of MechatronicUML developer and user.
Both, the evaluation result and the catalog, serve to specify a dependency language
that contains all common dependency kinds. Thereafter, the thesis implements a
partial synthesis algorithm for MechatronicUML due to the time limitation. It
is based upon model transformation techniques. The analysis steps, like conflict
analysis and refinement check, are not included in this thesis.
This work uses Eckardt’s [Eck09] and Henkler’s [EH10, Hen12] idea to introduce an
explicit dependency language. However, it uses neither their dependency language
nor synthesis algorithm because it discovers many new dependency kinds which are
unsupported by these. Furthermore, they neither meet the thesis’s requirements,
e.g., traceability (see Chapters 3 and 4). This work further includes a more detailed differentiation of dependencies referring to their purposes. Additionally, it is
not based on any other synthesis algorithm (see Chapter 5) because most of them
are working with behaviors that are not nearly as expressive as MechatronicUML’s Real-Time Statecharts. For example, they do not contain data, time, or
concurrency.
1.4 Document Structure
The document continues in Chapter 2 with a detailed description of fundamentals.
Chapter 3 then describes the synthesis method in detail. Thereafter, Chapter 4
describes the application of this method to MechatronicUML. Chapter 5 presents
a comparison of related work. The thesis closes in Chapter 6 with a conclusion and
a summary of open issues to be covered by future work.
8
2 Fundamentals
The following sections describe all basics needed to understand the techniques and
technologies mentioned in upcoming chapters. The chapter opens with a summary
of Model-Driven Software Development in Section 2.1. It continues with a description of Domain Specific Languages and the development of modeling languages in
general in Section 2.2. Next, the specific details of textual languages are described
in Section 2.3. This is followed by Section 2.4, which introduces the model transformations. Then, the timed automaton and formal verification are presented in
Sections 2.5 and 2.6, respectively. Section 2.7 goes on to explain a compositional
verification approach. Continuing forward, Section 2.8 briefly describes the MechatronicUML method, which bases on all previously explained basics. Lastly, Section 2.9 presents the idea of the Goal Question Metric evaluation technique.
2.1 Model-Driven Software Development
The history of software development can be traced back to the 20th century. In
its beginnings, software was programmed using punch cards. Over the generations,
it developed further, first with general purpose languages (GPL) like Assembler
and later with high-level GPLs like C, C++, or JAVA. The commonality among
these languages is that they are all abstractions of machine code, meaning that they
abstract from the concrete code and focus on the functionality. The development of
abstraction was a necessity due to the growing complexity of software projects. Next
to the abstraction of machine code, there are other considerations which became
important to software development, e.g., safety, security, interaction, etc. Thus, it
was only natural that developers began abstracting various models for different fields
from source code and using these to work through their concerns and problems.
Model “A formal representation of entities and relationships in the real world (abstraction) with a certain correspondence (homomorphism) for a certain purpose (pragmatics).” [Sta73, cf. 131-133]
At first, these models were mainly used to communicate about and document programs. Thereafter, models started to be developed prior to their implementation.
As described in the methodology of Model-based Software Development [SVB+ 06,
cf. p.3] as well as in the IEEE standard, Software Design Descriptions [IEE09, cf.
p.3] are additionally used to specify requirements and design decisions. However,
through this earlier specification of the models, they require constant adaptation
throughout the implementation phases to remain consistent. This adaptation can
9
2. Fundamentals
become sophisticated and time-consuming. In some cases, it may even fail to yield
any benefit for the developer except for that of accurate documentation. Hence,
developers often neglect to maintain of the models.
To overcome the problems of models ultimately being wasted effort, except for their
use as documentation, the Model-Driven Software Development (MDSD) places the
model at the center of its methodology. [SVB+ 06, cf. p.4] It no longer uses a model
solely for documentation purposes, but instead focuses on it as the central softwaredefining artifact. In the MDSD, models are used to generate software, meaning that
all relevant information for the generation process is provided by the models. This
concept is shared by current GPLs. Their source code can be executed through
either compilation or interpretation. The same can be accomplished with every
kind of MDSD model. Therefore, they can be compiled, interpreted, or transformed
into immediately executable model. Thus, use of the models requires merely an
understanding of their semantics but not necessarily how they can are executed.
MDSD belongs to the category of forward engineering approaches. Furthermore,
it strictly disallows manual changes at (intermediate) results, meaning that the
developer may alter the resulting program only by modifying the model or the
generating software (transformation, generation, or interpreter). This restriction
guarantees consistency among the models. [SVB+ 06] However, a generative approach
like MDSD requires that its models be formally defined. The upcoming Section 2.2
describes how this could be accomplished.
As its name implies, the Domain-Specific Language (DSL) is designed for a specific
domain.
Domain A domain “describes a bounded field of interest or knowledge.” [SVB+ 06,
p.56].
Thus, the language does not cover the expressiveness of a GPL. It is restricted to
descriptive knowledge of its specific scope, e.g., embedded systems, databases, or
websites. The transition between DSL and GPL is smooth. That is, a language
can be more or less domain-specific. Völter et al. [VBD+ 13] determined a set of
language characteristics which can be used to roughly distinguish both kinds. These
are shown in Table 2.1. As DSLs, they consider typically the languages which tends
to match with more of the DSLs column of Table 2.1 . Nevertheless, there are several
DSLs like HTML, SQL, etc., that do not fit into this categorization. In my opinion,
the most important characteristic of GPL is its Turing completeness, because it
highlights the interchangeability of GPLs. DSLs are typically noninterchangeable.
Accordingly, you could say that every language which is not Turing complete must
be somehow domain-specific.
A DSL, like every formal language, requires the following definitions:
10
Domain
Language size
Turing completeness
User-defined abstractions
Execution
Lifespan
Designed by
User community
Evolution
Deprecation/incompatible changes
GPLs
large and complex
large
always
sophisticated
via intermediate GPL
years to decades
guru or commitee
large, anonymous and widespread
slow, often standardized
almost impossible
DSLs
smaller and well-defined
small
often not
limited
native
month to years (driven by context)
a few engineers and domain experts
small, accessible and local
fast-paced
feasible
Table 2.1: GPL vs. DSL. GPLs tend to match more characteristics from the middle
and DSLs tend to match more from the right column . [VBD+ 13, p.31]
Abstract Syntax “The abstract syntax merely specifies what the language’s structure looks like.” [SVB+ 06, p.57] In general, the abstract syntax describes the
structure with the help of class diagrams, containing components and its attributes and references.1 It also defines the internal representation of a model.
Static Semantics “The static semantics of a language determine its criteria for
well-formedness. A typical example of the world of programming languages is
the rule that variables must be declared before they are used. The syntax of
a language [...] typically cannot determine this.” [SVB+ 06, p.58] The static
semantics could for instance be defined with OCL expressions [OCL12].
Meta Model “The meta model compasses the abstract syntax and the static semantics of a language, and is an instance of the meta meta model.” [SVB+ 06,
p.57] The meta meta model that is used to describe the meta model is typically the Object Management Group (OMG) standard Meta Object Facility
(MOF) [MOF11] which is self descriptive2 . The meta model describes all
“words and sentences” that are contained in the language. A model is an
instance of its meta model and can be seen as one sentence of the language.
Concrete Syntax The concrete syntax defines how models are represented and how
developers can specify them. A concrete syntax could be textual, graphical,
symbolic, table-based, or a mix of these. The concrete syntax must be unambiguous, because a parser or projection must be able to distinguish its corresponding abstract element. The number of concrete syntaxes is unbounded.
As a consequence, there can be several concrete syntaxes for one abstract syntax. For example, consider that your meta-model contains a single object type
called Component. Assume each component can contain other components.
An abstract model consisting of a component α containing a component β,
could be illustrated graphically as well as textually, as shown as Figure 2.1.
1
2
In some cases, such as with XText, the abstract syntax is generated from the grammar.
MOF is its own meta model and so there is no infinite chain of meta models.
11
2. Fundamentals
(a)
(b)
α
β
Comp α {
Comp β {}
}
Figure 2.1: Concrete Syntaxes: (a) Graphical and (b) Textual
Dynamic Semantics Specifying dynamic semantics is probably the most effortful
part of the language definition. It specifies the meaning of all elements of
a language. The formal specification can be done through an execution engine [VBD+ 13, cf. p.27], which renders the model executable. Therefore, this
engine uses a translation (transformation or compilation) or an interpretation. The transformation maps the model to a semantically equivalent model,
that is of directly executable language.3 A compilation generates executable
code. This could be binary code such as that from compiled C programs or
interpretable code like Java Byte code. The interpretation is the only kind of
execution which immediately executes the model. This has the additional benefit of allowing dynamic changes to the model. Note that the definition could
be carried out informally (using natural language), but without a formally
defined semantic, a language cannot be used in an MDSD approach.
Next to the definition of the domain, syntax, and semantics, the development of a
languages should include the definition of the following aspects: The stakeholder,
viewpoints, and views. [Hil99] Stakeholders are the persons with an interest in the
language, e.g., domain engineers, managers, and also clients. A language can have
several viewpoints, such as structure and behavior, which can usually be developed
independently. Each viewpoint may contain several views. In views, all irrelevant
parts of the model may be faded out. This is one obvious difference from concrete
syntaxes, which normally should cover all elements. However, several views can
build a concrete syntax.
2.3 Textual Languages
In a textual language, as the term implies, text is used to define a model. Therefore,
a concrete syntax must define how text can be mapped to abstract syntax. Typically, this is done in an EBNF-grammar [Wir77]. The grammar contains multiple
production rules, terminals, and non-terminals. Each rule describes how a nonterminal can be replaced by a combination of terminals (symbols, characters, and
numbers) and other non-terminals [Bar02, cf. p.69]. Additionally, one rule is the
start rule. Beginning with the start rule, the grammar can construct any element of
3
The transformation chain is unlimited only if it is non-circular.
12
2.4 Model Transformation
the language resp. meta model. However, the text is usually not constructed automatically by the grammar, but manually. Consequently, the text must be translated
into the abstract syntax by a parser. The parser identifies whether the text can be
constructed through the grammar and which non-terminals are used. If the model
cannot be constructed, it generates error messages specifying which text parts might
have produced the error and a guess about what might have been missing from a
correct language element.
With a grammar, a parser, and the meta model the rudimentary textual language
is complete. However, modern textual languages additionally include code completion, text highlighting, outlines, live syntax analysis, etc. These features can be
provided through textual language creation frameworks like XText [Ecl13]. XText
offers language integration within the Eclipse IDE and uses the Eclipse Modeling
Framework (EMF) as basis for the abstract model. Since the MechatronicUML
presented later is also based on the EMF, the language described in Section 4.4 will
be developed using XText.
2.4 Model Transformation
The model transformation uses a source model to create or modify a target model or
text. [CH06] Therefore, it maps source objects to target objects according to rules.
Those rules can look differently depending on the model transformation technique
used.
The model transformation accomplishes various usages. It can change the abstraction level (vertical transformations), e.g., by adding platform-specific information.
Another usage is a transformation into a semantically equivalent model (horizontal
transformation), e.g., to verify the model with the aid of already existing analysis
tools. Also, horizontal transformations can be used to define dynamic semantics
indirectly through another language’s semantics [CSN08].
Model transformation and its techniques have been further characterized [CH03,
MCG05, Vis01]. Here are a few characteristics which distinguish them:
Output Transformations can transform models into text (called model-to-text or
generator) and into models (called model-to-model).
Source-Target Relationship The target model can either already exist or not. If
it does not exist, the transformation creates it. If it does, the transformation
modifies the existing model. Here, it is possible to further separate between Inplace and Update. In-place states that the target model is actually the source
model itself. Update states that the target model is not the same as the source
model and will be updated (modified) according to the transformation rules.
Direction The transformation can either be bidirectional or unidirectional. If it is
bidirectional, it can transform the source model into the target model and vice
versa. If it is unidirectional, only one of these directions is possible.
13
2. Fundamentals
Traceability Transformations can be categorized on the basis of whether they store
traces of the reasons why they created a target element. These traces allow to
follow the path back from every created target element to its sources, which
is an important feature for debugging purposes. They further resolve a source
element to a target such that references to source elements can also be mapped.
A broader overview of many distinctive features can be found in Czarnecki’s and
Helsen’s paper [CH06].
Furthermore, this thesis uses the term incremental transformation [GW09], if the
transformation preserves already transformed parts, it minimizes effort and enables
step-wise processing which is useful to modularize the transformation.
There are different transformation techniques, e.g., graphical like Triple Graph
Grammars [KW07] and Story Diagrams [THHO08] or textual like ATL [JAB+ 06]
or QVT [QVT11]. They are distinguished by their support for transformation features and are differently suitable depending on the application scenario [Leh12]. The
Query/View/Transformation (QVT) standard of OMG is one of the few transformation techniques that offers an almost mature open source transformation engine.
It uses the OCL [OCL12] of OMG to query elements and allows specification of
mappings between source and target model. During the transformation, it stores
which mappings have been used to transform elements. This makes possible queries
regarding the origin of target elements. The synthesis algorithm of Section 4.5 uses
the QVT operational mapping implemented in Eclipse [Dvo08]. It is an imperative,
unidirectional, traceable, model-to-model transformation language and supports all
kinds of source-target relationships.
2.5 Timed Automaton
An Uppaal timed automaton [BLL+ 96, BY04] is a finite automaton extended by
real-time clocks and data. Its clocks run in synchrony, such that specification of
real-time behavior becomes possible. Additionally, a timed automaton can build
up synchronous networks using synchronization channels. Using these, Timed Automata allow modeling, simulation and analysis of complex real-time behavior. Furthermore, they enable formal verifying safety and liveness properties.
The following describes its syntax elements and its semantics using the example of
Figure 2.2. The figure presents two timed automata, each with three states. The
gray annotations declare what kind of syntax element are shown. The left automaton has the states idle, CheckRequest, and EnterAllowed. Furthermore, it makes
use of the clock c2 and the boolean variable free. The idle state is the initial state
indicated by the second circle. Each state can be restricted by an invariant (purple).
The state must be left when the invariant does not hold any more. This can be solely
done by transitions. Thus, transitions indicate state changes. Each transition can
contain assignments (dark blue), synchronization channels (light blue), and guards
14
2.6 Formal Verification
state
name
idle
enterDenied!
guard
c2>=50 && not free
c2:=0
CheckRequest
request?
c2<=10
c2 <= 60
sectionLeft?
c2:=0
channel
enterAllowed!
c2>=50 && free
EnterAllowed
c2 <= 250
idle
enterDenied?
c1:=0
request!
c1<=5
c1:=0
sectionLeft!
c1:=0
assignment
WaitForAnswer
c1<=60
invariant
enterAllowed?
Drive
c1<=200
Figure 2.2: Syntax of Timed Automata Network
(green). Assignments can change data or reset clocks. Guards can restrict a transition’s usage. They contain a boolean formula which can consist of clock constraints
and data constraints. Via channels, synchronous signals can be sent and received between timed automata. This makes building a timed automata network possible. In
Figure 2.2, there are four channels (request, sectionLeft, enterAllowed, enterDenied).
The exclamation mark ‘!’ indicates that the transition sends a synchronization and
question mark ‘?’ indicates that it awaits to receive a synchronization.
So, the beginning at the initial state idle of the left automaton their is only one
outgoing transition. This transition waits for a signal at the request channel and
solely fire if the signal is received and the value of clock c2 does not exceed ten time
units. The transition leads to a state change from idle to CheckRequest, which may
remain active until the value of clock c2 ’ exceeds 60 time units. From CheckRequest,
two transitions are possible. The first sends an enterDenied signal if the variable
free is false and the clock c2 is at 50 time units. The transition further resets the
clock c2. The second sends an enterAllowed signal if free is true and c2 is at 50
time units. It does not contain an assignment. Both transitions require that another
timed automaton is waiting to receive the synchronization signal. The remaining
transition and state are working analogously. The next section describes how such
behavior can be verified.
In safety-critical software development domains like mechatronic systems, it is of
particular importance that the software guarantees certain properties, e.g., deadlock
freedom. Such properties cannot be proven by tests. “Testing shows the presence,
not the absence of bugs.” [BR69, E.W. Dijkstra, p.16] The absence can only be
proven with mathematical methods. Such proof is know as formal verification. In
the remaining, the term correct indicates that all specified properties of a model
resp. a program are formal verified.
15
2. Fundamentals
2.6.1 Formal Properties
Mathematical methods require for formal verification that the model and properties
are specified formally. Depending on the mathematical method, there are different formal language options, e.g., Z-Notation [Spi89], LTL [Pnu77], CTL [Eme90],
TCTL [ACD93], and OCL/RT [CK02]. We will focus on state-based behavior models and so mainly on CTL and its derivations to specify properties. CTL, the
computational tree logic, is an extension of propositional formulas. With CTL,
paths containing relations between propositional formulas can be specified. For example, on all execution paths, formula α holds until formula β holds. Therefore, it
offers existence- and all-quantifier. Additionally, the relations of propositional formulas can be described through four expressions: Next, Future, Until, and Global.
These relations must always be combined with a quantifier. The Next relation expresses that one / all directly connected states must hold for a certain formula. The
Future relation specifies that for one / all paths somewhere in the future the formula
holds. The Until relation expresses that there is one / all paths on which a first
formula holds until a second formula holds. The Global specifies that a formula
holds globally (in every state) for one / all paths. As an extension of CTL, the
TCTL extends the CTL by time. That is, it may include clock constraints within
the formulas. For example, one could require that the Timed Automata of Figure 2.2
must fulfill the property that the EnterAllowed state is only allowed when clock c2
is between 50 and 250. Figure 2.3 expresses this property in TCTL syntax4 .
AG (not EnterAllowed or (c2>=50 and c2<=250))
Figure 2.3: TCTL Property Example
2.6.2 Model Checking
In state-based behavior development, the formal verification can be done according to the model checking approach. This approach was developed to verify that a
Kripke structure is a correct model for a formula (property). [Cla08, cf. p.2] The
approach checks whether CTL formulas are true or false. Therefore, the approach explores the complete state space. This exploration requires polynomial time.[CGP00]
Newer approaches like symbolic model checking reduce the global state space by
concatenating states into symbolic states, drastically improving the execution time,
but nonetheless remain polynomial with respect to the number of global states.
Furthermore, all model checking approaches have a common problem, i.e., the state
explosion, which is when the number of reachable states (state space) is exponential (compared with the number of specified states) through concurrent running
automata. Thereby, large systems could not be model checked in their entirety.
4
In many implementations of TCTL, Global is indicated by the square symbol .
16
Later, timed model checking was introduced. It enables validating timed behavior.
A state-of-the-art timed model checker is Uppaal [BLL+ 96]. In contrast to the
original approach, it allows modeling and checking Timed Automata. To specify
timing constraints in properties, Uppaal supports a subset of TCTL5 , making it
capable of validating real-time systems. For example, it can verify that Figure 2.2
holds the property of Figure 2.3.
2.6.3 Refinement Check
The refinement check is an approach that expects a verified model and a refined
model. A refined model is a model based on the verified model. It is enriched in its
details and can be more specific in its constraints. For example, Figure 2.4 shows a
refinement of the left Timed Automaton from Figure 2.2. It restricts the transition
from CheckRequest to EnterAllowed through a constraint that reduces the time
interval for clock c2 from [50,60] to [55,60].
idle
enterDenied!
c2>=50 && not free
c2:=0
CheckRequest
request?
c2<=10
c2 <= 60
sectionLeft?
c2:=0
enterAllowed!
c2>=55 && free
EnterAllowed
c2 <= 250
Figure 2.4: Refinement of the left Timed Automaton of Figure 2.2
The refinement check analyzes both models and so can check whether the verified
properties are still valid. Depending on the property kind - existence or all quantifier
- and the kind of features the state-based model uses, e.g., timings and buffers,
different refinement checks are used. [BHSH13] In the example from Figure 2.4, the
refinement check would prove that the property of Figure 2.3 is still valid.
The basic idea of the approach is that refined models preserve certain properties
of the original model, as long as the refined model does not extend the behavior through new message sequences or loosened constraints. This can be proven
through simulation or bisimulation. Thereby, the refinement check is a more efficient verification approach for refined models than a second model check. [HH11]
This makes it suitable for situations in which the model checker fails due to the
state explosion.
5
For example, within Uppaal, nested expressions are currently not supported.
17
2. Fundamentals
2.7 Compositional Verification Approach
In the MDSD, today’s software systems are highly complex and often distributed.
Their verification can no longer rely solely upon model checking techniques due to the
state explosion problem as previously described. Giese proposed a compositional approach that tackles the problem for state-based real-time software systems [Gie03].
It is based on the assume/guarantee paradigm [MC81] and divides systems into
small components. A separation is made between synchronous and asynchronous
communication. Synchronous communication is then only possible within a single component, whereas asynchronous communication occurs only between different
components. A component consists of several ports (for asynchronous communication) and an internal behavior. Because of the asynchrony of inter-component
communication, the approach does not allow global system clocks.
The compositional development and verification works as shown in Figure 2.5. It
consists of three specification steps, which include two verification steps [Gie03, cf.
p.32]:
ProtocolName
Protocol
Specification
Requirements
role1
Protocols
Model Checking
1
Component
Specification
role2
Model Checking +
Refinement Check
2
ComponentBehavior
noPlatoon
Sync!
NextSection
clock: cf;
[cf > 999]
default
wait
cf ≤ 1000
entry / {reset: cf}
platoonProposal /
platoonProposal /
[cf <= 500]
:Track
/ startPlatoon
se
b
on
cti
Se
cti
on
3 System
3
artefact
:Railcab
Se
Legend
b
Components
incl. Behavior
ca
waiting
ce ≤ 500
entry / {reset: ce}
:Track
next
En
ter
/ requestUpdate
performUpdate /
prev
c
default
ce ≤ 2000
entry / {reset: ce}
ter
En
clock: ce;
Sync?
/ unregister
se
System Composition
using Protocols
and Components
registered
/ register
unregistered
c
platoon
:Component
ca
/ breakPlatoon
process step
integrated analysis step
Figure 2.5: Development Steps of Compositional Verification
1. Using the compositional approach, the developer begins by specifying the asynchronous communication between components. This happens in protocols6
which contain roles like registrar and registry. These roles are small statebased behaviors connected by cable or wireless signals. They specify message
sequences and timings.
These protocols are simple enough to verify with respect to local properties
using a timed model checker.
6
In Giese’s paper [Gie03], they are called patterns.
18
2.7 Compositional Verification Approach
2. The verified protocols are used during the component specification. The developer begins the specification through modeling the components structure,
e.g., how many ports it contains. Thereafter, he specifies the component’s behavior. Giese has not described how this can be done in detail. One possibility
is described in the following two sub-steps:
a) The approach assumes that connections can only exist between ports
that refine connected roles. Hence, the developer must assign a protocol
role to each component’s port. Thereafter, the ports’ behaviors must be
modeled, refining the role’s behavior.
Using refinement checks, the developer can check whether all verified role
properties still hold within the ports’ behaviors.
b) Thereafter, the component behavior consists of verified independent ports’
behaviors. The second sub-step for the component’s behavior specification is the integration of dependencies and inner-behavior. This could
be done either through a manual synthesis or through additional models
(dependency model and inner-behavior model), which are then fed into a
synthesis algorithm to automatically generate the component’s behavior.7
Finally, all ports’ behaviors and calculations are composed in a state-based
component behavior and they are connected either by a parallel composition
or by synchronizations and auxiliary regions.
The specified components must be verified. Whether the verified properties
of the ports’ behaviors (resp. protocols’ roles) are still valid, can be shown
by a refinement check. Furthermore, additional local properties that single
components must fulfill can be verified through timed model checking.
3. Finally, the verified components can be connected according to the protocols.
Thereby, it becomes possible to compose systems that ensure all previously
verified properties.
The described process modularizes the behavior of the system and verifies the components separately, because each component only requires that the connected components fulfill the specified behavior from their protocol’s roles. The result is a
composed verified system.
It is worth noting that the approach only verifies local properties (at the protocol and component level). Thus, if there are global properties which cannot be
substituted through local ones, either they remain unverified or the compositional
verification requires an extension similar to what Hirsch and Giese [HG03] describe.
Furthermore, the approach does not consider data, but its application to models
that include data is assumed. Nevertheless, this remains to be proven in future
work.
7
The automatic variant is mentioned by Giese as step 3’ [Gie03, cf. p.33].
19
2. Fundamentals
2.8 MechatronicUML
Mechatronic systems8 are safety-critical and work in real-time. For their software
development, they require a domain-specific method that provides a process and a
language. To this end, UML [UML11] is unsuitable because it does not cover realtime behavior. The MechatronicUML [BBB+ 12] method, which is developed at
the University of Paderborn, is explicitly designed for mechatronic systems.
MechatronicUML is designed for software architects, engineers (safety, behavior,
mechanical, protocol, etc.), and clients. It covers structural and behavioral parts of
the software system and reuses concepts of the UML. Its models describe (hierarchical) Components, Component Instance Configurations, Real-Time Coordination
Protocols, Real-Time Statecharts, etc. It splits between discrete and continuous software. Thereby, the software engineer can focus on the discrete part. This further
enables timed model checking through Timed Automata and Uppaal. MechatronicUML’s development process forces a strict development and verification
order. Its process and language are geared towards the compositional verification
concept of Giese [Gie03] described in Section 2.7. Hence, using MechatronicUML
helps create correct software.
We consider MechatronicUML to be a MDSD process, meaning that it uses formal models, model checking, model transformations, and code generations to build
qualitative software. However, the current tooling and language implementation
nonetheless lacks in the completeness of its formal dynamic semantics.
The following sections provide a partial overview of MechatronicUML only containing the elements that are important for this work. It first proceeds with a
description of a subset of syntactical elements. Afterwards, it follows a short description how parts of the development process are working. MechatronicUML
also covers aspects like reconfiguration and multi-ports, but those are not considered
here.
2.8.1 Structure
MechatronicUML applies a component-based system design. It supports two
kinds of Component as illustrated in Figure 2.6. A component can be either an
Atomic or Structured Component. An atomic component like CrossingSW contains
a behavior, whereas a structured component like RailRoadCrossing contains subcomponents. Both kinds require Ports for interconnection. Atomic components can
be further distinguished by their port types (discrete, continuous, and hybrid). Discrete atomic components contain only discrete and hybrid ports, while continuous
atomic components contain continuous ports. To connect components two types of
Connectors are used: Assemblies and Delegations. Assemblies connect components
8
Mechatronic is also known by the term ‘cyber-physical’.
20
2.8 MechatronicUML
atomic component
precedingSection
discrete port
left
structured component
precedingSection
RailRoadCrossing
right
CrossingSW
precedingSection
left
left
:CrossingSW
gateAction
gateStatus
gateAction
gateStatus
hybrid port
assembly
action
status
right
right
component
name
status
component
part
action
:Gate
Gate
permanentClose
delegation
permanentClose
continous port
permanentClose
port name
Figure 2.6: Syntax of MechatronicUML’s Component
on the same hierarchical level (e.g. sub-components) Delegations connect components which are separated by one level. The behavior of structured components is
thus determined through the setup of their sub-components, assemblies and delegations. Connections can only be established between the following pairs: (discrete,
discrete); (continuous, hybrid); (continuous, continuous). Thus, discrete components can only connect with continuous components via hybrid port.
The above described components are used as types. Each component type is described once and can be instantiated multiple times. The structure of a system
is described in the Component Instance Configuration (CIC). There, instances of
components can be arranged using assembly instances to connect their port instances. As with structured components, the system’s behavior is determined by
all instantiated components and their connection instances. Figure 2.7 shows the
railcab scenario of Figure 1.1 in CIC syntax, containing two instances of Railcab and
NormalTrackSection, and one of Switch, and RailRoadCrossing.
left
right
ts1:Normal
TrackSection
right
left
sec1
r1:RailCab
sec2
bottom
ts3:Switch
ts4:RailRoad
Crossing
following
Section1
preceding
Section
right
ts2:Normal
TrackSection
r2:RailCab
sec1
sec2
Figure 2.7: Examplary Component Instance Configuration
21
2. Fundamentals
2.8.2 Behavior
As the compositional verification splits the behavior into inter-behavior and intrabehavior, the inter-behavior is specified through Real-Time Coordination Protocols
and the intra-behavior through components’ Real-Time Statecharts. Both are explained in greater detail in Sections 2.8.2.1 and 2.8.2.2, respectively.
2.8.2.1 Real-Time Coordination Protocol
A Real-Time Coordination Protocol9 describes the asynchronous unidirectional or
bidirectional communication allowed between two roles (components). Figure 2.8
shows an example of a Real-Time Coordination Protocol including gray syntax description labels. It consists of two roles (railcab and section). Its communication
direction is specified through the port types. Further, it specifies how the roles are
connected (with wire or wireless), including a maximum latency. The protocol role
using Real-Time Statechart to describe when and what asynchronous messages can
be accepted or sent.
Each specified connection of the system has to obey one such protocol. Thus, all connected ports must refine the protocol’s roles. Therefore, each discrete port contains
its own Real-Time Statechart.
protocol name
EnterSection
role name
railcab
section port type
delay: 20ms
buffer size: 1
buffer size: 1
connection type
Figure 2.8: Syntax of Real-Time Coordination Protocol
2.8.2.2 Real-Time Statechart
Real-Time Statechart is a state-based approach, which specifies message sequences.
Additionally, real-time requirements which must be defined in the behavior exist in
mechatronic systems. Therefore, the Real-Time Statechart combines Uppaal Timed
Automata [BLL+ 96] with UML Statemachines [UML11]. It is able to handle timing
constraints through clocks as well as to define concurrency through hierarchical resp.
complex states.
9
In MechatronicUML documentation [BBB+ 12], these protocols are called ‘patterns’. However, in the upcoming version 0.4, it will be replaced by the term ‘protocol’.
22
2.8 MechatronicUML
Its syntax is shown in Figure 2.9. A Real-Time Statechart must include one initial
state, in this case the state Waiting. It additionally can contain further States,
Transitions, Variables, and Clocks. The following paragraphs describe the existing
elements and their semantics in detail:
statechart name
variable and clocks definitions
Railcab
state
name
invariant
state
side
effects
variable int i, bool b clock c1, c2
receiver
clock
synchronization
message
constraint
target
[c1<=10] [i<5] enterAllowed sectionEnd? state
Waiting
/ {i++;} {reset: c2}
invariant c1 < 15, c2 < 25
entry / {reset: c1,c2}
Driving
clock
exit / {action} {reset: c1}
transition sender
urgent
reset
action message
transition
[c2>=20] / request {i := int<0,3>; b:=false}
source
sign for
initial
state
variable
guard
state
non-urgent transition
non-deterministic choice
Figure 2.9: Syntax of Real-Time Statechart
1) State A state refers to a specific configuration of the system and the active state
determines its current behavior. It may consist of Actions and Invariants. Further,
a state could be hierarchical and compose Regions with sub-states. It might also
contain Channels for the synchronization of sub-states.
2) Transition Transitions describe the change from one state to another, e.g., from
Waiting to Driving. They may specify actions, e.g., variable manipulations and clock
resets. Furthermore, they can specify Conditions for their activation. Conditions
could be Guards, received Messages, or Synchronizations. If the transition needs to
be used immediately as its conditions are met, this can be specified through urgent
transitions. Additionally, each transition can specify sending messages.
3) Clock Clocks are elements which track the passing of time. In Figure 2.9, two
clocks (c1 and c2) are defined. They are inherited from Timed Automata. They
use real-values and are synchronously incremented. They can be used in guards and
invariants to specify real-time constraints.
4) Variables Data is stored and processed using Variables. In Figure 2.9, an
integer variable (i) and a boolean variable (b) are defined. They can be manipulated
by actions, employed as conditions in guards, and used in Assignments, Operations,
and messages as Parameters.
23
2. Fundamentals
5) Guard Guards are boolean expressions. They can contain clocks, variables,
and operations. A guard prevents the use of a transition for as long as it evaluates
to false.
6) Message A message is transmitted asynchronous. It is used for the intercomponent coordination. For Real-Time Statecharts and regions that belong to a
port, incoming and outgoing messages can be specified. Incoming messages can
be consumed through a receiving message specification at a transition, e.g., the
enterAllowed message at the transition from Waiting to Driving. The transition
is only allowed to be used if the port received the message. A sending message
specification determines that if the transition is used the belonging port must send
it, e.g., the request message at the non-urgent transition from Driving to Waiting.
Such messages may contain arbitrary parameters.
7) Action An action can either be a clock reset, a variable assignment, or an
operation. It can be specified for different events, e.g., state entry or transition usage.
It typically changes the global system status. The clock reset restarts counting
time, through which the clock constraints might change their result. The variable
assignment allows simple calculations and data manipulation which may further
influence the evaluation of guards. The operations can trigger complex calculations
and user interface manipulations.
8) Invariants Invariants specify safety properties which must be true while a state
is active. A state cannot be entered if its invariant is not fulfilled. So, it is another
indirect condition to all incoming transitions. The invariants can further be used
as ultimate deadlines for the scheduling of state changes in platform-specific implementations.
Currently, only upper-bounded clock constraints can be used. However, this might
be extended someday, because the current Uppaal Timed Automata already allow
using any expression that evaluates to boolean.
9) Regions Regions specify internal behavior of states. Therefore, each region
contains another Real-Time Statechart. In Figure 2.9, there are no complex states
and consequentially no regions. Using regions allows the construction of hierarchical
states, which is especially useful for refinement purposes. Furthermore, it makes it
possible to split complex behavior into smaller, precise sub-states. Additionally,
multiple regions can be used to specify parallel behavior. For their coordination,
regions can share variables, channels and clocks. Of note that the impossibility
of asynchronous message exchange between regions enables a strict separation of
external and internal coordination.
24
2.8 MechatronicUML
10) Channel / Synchronization In RTSCs, the medium for synchronous communication is a channel. It allows coordination between different regions of one
state. Via channels, signals can be sent from a transition to synchronize with one
receiving transition. A transition that sends via a channel is indicated through the
name of the channel and the suffix “!”, one that receives through the suffix “?”, e.g.,
sectionEnd?. The sending as well as the receiving transition can only be used in
combination. The channels are inherited from Timed Automata, too. However, urgency is not definable via channels in Real-Time Statechart, instead this is declared
through the transition.
2.8.3 Development Process
The development process starts with the structural part of the system. Therein,
different types of components can be created and connected. Next, the message
types and protocols are defined. A catalog of protocol patterns for this purpose exists. [DBHT12] Having defined protocols, the developer verifies the properties of each
protocol. This can be done with a timed model checker, e.g., with Uppaal [Ger13].
Afterwards, he specifies the protocol role that each discrete port has to follow. The
referenced protocol roles can then be copied into the Real-Time Statecharts of discrete ports. Continually, the developer refines these Real-Time Statecharts. If this
is done, the refined Real-Time Statecharts are verified again, but this time using a
refinement check. Now we have all ports’ behaviors validly specified and we must
connect all of them inside one component’s behavior. This connection of port behaviors as mentioned in the introduction can currently only be done manually, and its
efficient specification is the main goal of this thesis. The final component behavior
then undergoes a refinement check to validate that it still conforms to all its ports’
behavior. Finally, all components are verified and can be transformed for execution
into source code, into other models for simulation platforms, or interpreted.
The global system is correctly specified if the process has been followed precisely,
because it uses the compositional verification approach proposed by Giese [Gie03].
Giese showed that it suffices for a correct system that all protocols are valid, that the
components conform to their protocols, and that they be deadlock free. Thereby,
MechatronicUML circumvents the state explosion, which is often a problem in
mechatronic systems due to its concurrencies.
2.8.4 Demarcation to MDSD and DSL
In the following, the thesis describes how MechatronicUML differs from typical
MDSD approaches and DSLs. In contrast to typically MDSD approaches, refinements of software definition do not only happen in the source model but also in intermediate results of model transformations. Nevertheless, these intermediate results
can been seen as the actual source model, because the first model transformations
in fact just copy verified software parts and are later used for an easier verification
25
2. Fundamentals
through refinement checks. The MechatronicUML continues to conform to the
forward engineering approach, because no changes in the intermediate models are
allowed that destroy the refinement relation. Hence, an inconsistency can only occur
if a refinement check fails and then the refined model has to be fixed rather than the
source. Another difference to other MDSD approaches is its evolution. Typically, an
MDSD approach starts with a reference implementation and tries, step by step, to
abstract details through new models and model transformations which maps them
back to the original implementation. In MechatronicUML, no complete reference implementation exists. The development started with Timed Automaton and
the compositional verification approach. Those were used to create a new language
capable of specifying mechatronic systems. However, the formal semantics definition
is in working progress, i.e., code generation not yet fully supported.
MechatronicUML is also not a good example for a DSL. Looking back on Table 2.1, we can see that this table does not allow a good classification. Its domain is
quite complex. The language size is of at least medium size. Its execution is carried
out via intermediate DSLs or GPLs. Its evolution is slow; the first publications
already appeared in 2003 (e.g., [GBK+ 03]). This also leads to a long lifespan. Nevertheless, other characteristics of DSLs fit quite well. One example is the small size
of the user community, due to the language’s continual development. Furthermore,
the meta model is not fixed and it still comes to incompatible changes.
However, MechatronicUML is not yet a complete DSL. This might be indicated
through the beta status. Its formal semantics are still incomplete, such that not all
language elements can be processed during verification or generation.
2.9 GQM - Goal Question Metric
The field of software development experiences increasing complexity, which makes
it increasingly difficult to create qualitative software. The MDSD approach tries
to improve the manageability, functionality, and quality. Nevertheless, it does not
include an approach to measure quality.
The Goal Question Metric (GQM) approach [BCR94] fills this gap. It creates a systematic software quality measurement, in a goal-driven manner. Therefore, “GQM
defines a certain goal, refines this goal into questions, and defines metrics that should
provide the information to answer these questions.” [SB99, p.23]
It enables numerous tasks [SB99]:
“
•
•
•
•
26
planning of resource requirements before a project starts
evaluating the quality of products or processes
process improvements on top of adaptation and refinement
feedback with respect to the progress of a project
” [Ger13, p.31]
2.9 GQM - Goal Question Metric
2.9.1 GQM Process
GQM assumes a process of four phases that creates systematic measurements [SB99,
cf. p.22]:
1. The planning phase, during which a project plan is created, characterizing the
software and resources.
2. The definition phase, during which the quality management team defines and
documents goals, questions, metrics, and hypotheses.
3. The data collection phase, during which the actual data is collected and reported.
4. The interpretation phase, during which the GQM team processes the data to
answer the questions. The team compares it with the hypothesis and evaluates
whether the goals have been reached.
2.9.2 GQM Model
In the definition phase, the quality model is built. This consists of three different
levels: conceptual, operational, quantitative. [BCR94, cf. p.3]
1. The conceptual level defines goals. A goal is defined for an object like products,
processes, and resources, and for a variety of reasons. Furthermore, it defines
which qualities it shall measure.
2. The operational level consists of refinements of the previously declared goals. A
refinement is specified through one or more questions which try to characterize
the measurement objectives.
3. On the quantitative level, metrics describe how the questions should be answered in a quantitative way. Here, it is important that metrics be objective
or subjective depending on their independency of/dependence on a viewpoint.
27
3 Synthesis Method for Extended
Hierarchical Real-Time Behavior
The thesis focuses on the software component’s behavior development and its formal
verification, especially on extended hierarchical real-time behavior. Such behavior
may include asynchronous resp. synchronous messages, data manipulations, concurrency, and operations calls. It further allows specification of real-time constraints
and of hierarchies, e.g, complex states. However, the automatic synthesis method
presented here could also be applied to less expressive behaviors.
The thesis’ synthesis method is designed for development methods that separate
inter-behavior and intra-behavior.
Inter-behavior is externally visible behavior specified in independent coordination
protocols, and its roles are refined inside a component’s port. Its coordination
is assumed to be asynchronous.
Intra-behavior specifies its component’s behavior. It intersects with each interbehavior through its ports (green area in Figure 1.2 at page 2). Thus, it
must refine (see Section 2.6.3) its ports’ behaviors without introducing new,
externally visible behavior; only restrictions can be made. Inside the intrabehavior, dependencies can be specified through synchronizations, shared data,
clocks, etc.
Such separation is especially useful for the formal verification of large systems.
It allows, e.g., the use of the compositional verification approach developed by
Giese [Gie03]. However, Giese’s approach only enables verification of the system’s
correctness. It does not describe how the separated behaviors can be modeled. As
described in Section 1.1, this is a non-trivial task.
This synthesis method provides a solution for step 2b of the compositional verification (see Section 2.7). Furthermore, it provides a semi-automatic procedure to
correctly generate intra-behavior, i.e., intra-behavior in conformance with safety and
liveness properties of its inter-behaviors. Like Eckardt and Henkler [EH10, Hen12],
this thesis proposes to specify dependencies explicitly and use these for an automatic
synthesis of the intra-behavior. Figure 1.4 on page 6 depicts the steps of my synthesis method. Following this process shall yield a complete, traceable, repeatable,
and reliable component’s behavior.
29
3. Synthesis Method for Extended Hierarchical Real-Time Behavior
The automatic synthesis algorithm in Figure 1.4 requires three kinds of input:
1. Inter-Behaviors: Set of independent port behaviors.
2. Inner-Behavior: Internal component behavior independent of every interbehavior, e.g., for calculations, conversions, and internal states.
3. Dependencies: Dependencies between inter-behaviors and inner-behavior,
e.g. data transport, synchronizations, and message-sequences.
Thereby, the process order is predetermined. The algorithm requires models of step
one (inter-behaviors and inner-behavior specification) and step two (dependency
specification). So, step three cannot be done earlier. Furthermore, step two needs
to reference elements of the models specified in step one. Thus, the oder of step
one, two and three cannot be changed. Additionally, the step four avert insufficiencies that come from incomplete steps two and three. Hence, step four (manual
intra-behavior specification) is only required to implement behavioral requirements
that could either be not expressed as dependencies or automatically synthesized.
However, which requirements these are, can only be determined after step three.
In the assumed development methods, steps one and four of Figure 1.4 must already
be possible because they are mandatory specifications even without an explicit synthesis method. The author further assumes that development methods for safetycritical systems already include model checking and refinement checking, as these
are required to verify the behavior. However, the essential parts of this synthesis
method are step two (explicit specification of dependencies) and step three (automatic synthesis algorithm), respectively, which do not yet exist in most development
methods.
In the field of component behavior development, other automatic synthesis approaches that merge multiple behaviors into one already exist (see Chapter 5).
However, those approaches mainly concentrate on the synthesis algorithm. They
do not describe the integration of their algorithm with existing development methods. They differ further in their expressiveness of inter-behavior and intra-behavior.
Their behaviors mostly omit time, data, and concurrency, and no behavior of these
considers all. This synthesis method addresses behaviors which considers all. Furthermore, the other approaches do not distinguish possible dependency kinds. As
such, whether their dependency languages are complete often remains unclear. Additionally, some are even mixing inter-behavior with dependencies. Until now, the
closest approach to this thesis is from Eckardt and Henkler’s [EH10, Hen12]. However, none of the existing approaches suffice for the synthesis of extended hierarchical
real-time behavior. A detailed description of this insufficiency is provided in Chapter 5.
Section 3.1 continues with a detailed description of the synthesis method’s requirements, especially with respect to the development method’s process. Also covered is
the automatic synthesis algorithm and its input dependency language. Afterwards,
in Section 3.2, the thesis outlines how the synthesis method could be generally applied to software component development methods.
30
3.1 Requirements of Synthesis Method
3.1 Requirements of Synthesis Method
The synthesis method has several requirements. It must enable developing a verifiable, maintainable, traceable, repeatable intra-behavior:
Verifiability is essential for safety-critical systems to guarantee their correctness.
Thus, the method shall include process steps to verify where they are required
for early detection of errors.
Maintainability is required such that behavior engineers can debug and manually
adapt the intra-behavior. This shall further be useful for modeling of dependencies, which are not supported by the dependency language or synthesis
algorithm.
Traceability of requirements must be possible such that each element can be traced
back to its origin. Thereby, it can be checked if the intra-behavior has taken
every requirement into account.
Repeatability is needed if any claims are to be made regarding the behavior’s correctness. Furthermore, it is essential to reduce the development time.
Additionally, if any process exists besides the development language which is being
used, the automatic synthesis process must be integrated in this additional process.
Next, the synthesis method requires a dependency language as an input to synthesize an intra-behavior. Furthermore, the method requires an automatic synthesis
algorithm. In the following sections 3.1.1 to 3.1.3, we take a closer look at the
requirements of those three.
3.1.1 Requirements for Development Method and its Process
The subsequent requirements must be met by the development method and its process. They shall ensure that the development method produces a verified component
behavior through structured, debugable, and repeatable process steps.
1. The development method must meet the assumption that it separates the
behavior into inter-behaviors and intra-behavior.
2. The development method must integrate the dependency model specification
and synthesis into its process sequentially after the inter-behavior and innerbehavior specification (as shown in Figure 1.4). This makes referencing all
inter-behaviors during the dependency specification possible.
3. The process shall include a verification of the synthesis result in order to
make sure that the synthesized intra-behavior is correct. Using compositional
verification, the refinement check requires that the inter-behaviors and innerbehaviors are validated before.
31
4. In the case that an analysis step like model checking, refinement check, or
conflict analysis discovers an error, the process should describe how the developer must continue. This is important since a complex development cannot
disregard debugging.
5. The adapted process shall offer a better modularity through its explicit dependency model. Such that, the manual developed elements are better maintainable, re-usable, and verifiable.
6. The process shall allow focusing first on the most common dependencies during the language and synthesis algorithm implementation. This should reduce
the implementation complexity and enables a fast usage. Uncommon dependencies might only be expressible using special workarounds or are so rare
that including them inside the automatic synthesis algorithm would not be
worthwhile. Thus, the process still includes the option of manually modeling
dependencies within the intra-behavior.
7. The development process should optionally include conflict detection, because early detection of dependency inconsistencies saves development time.
Please note that the detection is however not required to ensure verified intrabehavior.
3.1.2 Requirements: Dependency Language
We need a dependency language because explicit, formal requirements are necessary
to the automatic synthesis. The language shall meet the following criteria: The
language ...
1. ... must be formal, in order to be usable as input to the synthesis algorithm.
This further makes the model analyzable to identify conflicts as early as possible
2. .. must contain a concrete syntax to explicitly express every common dependency. The language does not need to be complete (in regard to possible dependencies), because the synthesis method includes an optional manual
adaptation step. Furthermore, the explicit dependency model should provide
a single point of maintenance per component for dependencies, rather than
distributing these over several positions.
3. ... shall be language-specific and not general, such that language-specific referencing of inter-behavior and inner-behavior elements like messages, states
and variables becomes possible.
4. ... shall be accepted by behavior developers as well as by users without computer science backgrounds (clients). The language should further improve the
traceability of requirements.
32
3.2 Synthesis Method Application Procedure
5. ... shall contain as few basic dependencies as possible. This should reduce
the complexity, whereby the synthesis algorithm benefits, too. However, the
language is allowed to include abbreviations for common usages of basic dependencies and their combinations. This should improve the comprehension
and usability. It should not lead to further complexity for the algorithm as
the abbreviations can be normalized.
3.1.3 Requirements: Synthesis Algorithm
For the synthesis algorithm, my method has the following requirements:
1. The synthesis algorithm shall be fully automated. It should not require any
user inputs at run-time because it shall be repeatable without additional manual choices. This shall improve development time, especially when it comes
to changes of the inter-behaviors, inner-behavior or dependencies. Nevertheless, if the synthesis algorithm needs to offer modeling choices, they could be
provided through storable configuration parameters.
2. The algorithm shall use the inner-behavior, all ports’ inter-behaviors and the
dependency model as an input to synthesize intra-behavior.
3. The synthesized intra-behavior of this component must refine all inter-behaviors,
and inner-behavior correctly.
4. The synthesized intra-behavior of this component must further include all
dependencies specified within the dependency model.
5. The intra-behavior shall be traceable. This shall enable tracing the origins of
single elements, but also how and where the dependencies influenced the intrabehavior. This is important for debugging and to ensure that all requirements
are met.
6. The intra-behavior shall further be maintainable. It shall preserve the interbehaviors and inner-behavior structures, such that the behavior engineer is
able to understand and adapt the synthesized result if needed.
7. For the synthesis, the algorithm should use, if possible, a modeling (bestpractices) of each single dependency that is recommended from most behavior
engineers.
During the application of the synthesis method to MechatronicUML, the author
identified a general procedure for method developers to apply in order to integrate
the synthesis method into their software component development method. The
procedure consists of six steps, illustrated in Figure 3.1. Each step includes an
33
evaluation because the changes of the existing development method must be proven
in its usability and correctness, and further so that they enhance the development
method. In this procedure, the thesis assumes that the method already includes
intra-behavior and inter-behavior specification.
Method
without
auto. synthesis
2
1
Dependency Language
Development
4
Method’s
Process Adaptation
Method Analysis
Comprehension
Legend
Usability + Safety
Conflict Analysis
Algorithm Development
Correctness +
5
Completeness
artefact
process step
Dependency Kind
Analysis
3
User Acceptance
Automatic Synthesis
6
Traceability +
Maintainability +
Refinement
Method
with
auto. synthesis
integrated evaluation step
Figure 3.1: Procedure to Apply the Synthesis Method
3.2.1 Step 1: Method Analysis
The method developer needs to analyze his development method and compare
whether it meets the requirements. To this end, it can be useful to create a checklist
of the requirements. The analysis shall include the identification of the languages
which are used for the behavior specifications and how their verification is currently
done. Furthermore, the method developer must check whether the activity order
matches the requirements, e.g., that the process specifies first the inter-behavior and
then the intra-behavior. Also, he must identify if all required activities and artifacts
are included. Lastly, the developer should summarize the results of his analysis,
such that the remaining tasks for the following steps become clear.
3.2.2 Step 2: Method’s Process Adaptation
In the second step, if the process order does not meet the requirements, the method
developer must adapt it accordingly. This includes the addition of artifacts for the
dependency language and the inclusion of a dependency specification activity. The
developer shall extend the process by an automatic synthesis activity.
The resulting process has to be evaluated on the basis of its usability. The goal is
that the new process provides a comparable or shorter development time in regard
to a complete manual synthesis process.
34
3.2.3 Step 3: Dependency Kind Analysis
The analysis of dependencies begins with the identification of intra-behavior language elements that influence multiple inter-behaviors. In orthogonal systems, those
elements could be shared data, clocks, synchronizations, etc. Next, the elements’
usage must be analyzed in existing projects to determine dependencies. Domain experts like behavior engineers can additionally model common dependencies to assist
the method developer during the determination. This is especially useful when the
set of existing projects is small and if that set does not cover plausible and common
dependencies. Afterwards, the method developer must categorize the determined
dependencies into dependency kinds. Those kinds should describe their purpose
and provide an exemplary modeling. This helps to abstract from the modeling and
to focus on their purposes. It is an important step because the dependency kind
catalog determines the expressiveness of the new dependency language.
The catalog must be evaluated to identify whether it includes all common dependency kinds. Those which seldom occur could then be dropped to simplify the
synthesis algorithm and dependency language. This can be done through a survey
of behavior engineers. For the purpose of this thesis, commonly accepted dependency kinds are assumed to be plausible. This survey can further suggest the order
of their importance. For the evaluation, it is also possible to use a quantitative data
analysis. The ideal case is that in which multiple industrial-sized projects exist,
wherein the occurrence of various dependency kinds can be counted and thereby
prioritized.
3.2.4 Step 4: Dependency Language Development
The dependency language shall be based on the dependency kind catalog. The
method developer shall begin the language development with common dependency
kinds. The dependency language strongly depends on the behavior languages, dependency catalog, and stakeholders. The language’s syntax could, for example, be
done in the following styles:
Structured English A language like that described by Konrad and Cheng [KC05]
allows the expressions to be read almost like natural language, which enables
even clients to understand the specified dependencies. Furthermore, Structured English simplifies tracing of unformal requirements through their similarity. Nevertheless, Structured English can become ugly if the language requires nesting, and its usability might decrease behavior engineer’s efficient
compared to a compact mathematical syntax.
Graphical If the behavior is specified graphically, it can be useful to employ a graphical syntax for dependencies as well, e.g., this allows easily referencing of existing elements. However, the more elements are referenced in a dependency,
the more complex a graphical syntax may become.
35
Keywords A textual syntax could also use expressive keywords. This may not be as
compact as mathematical syntax, but it is a compromise between readability
and usability.
A general difficulty is referencing of existing behavior elements. For textual syntaxes,
it can be useful to rely on fully-qualified names.
In summary, the choice of syntax style (textual, graphical, etc.) is purely a matter
of taste. The author prefers to use a textual syntax with keywords. However, it
might also be possible to develop a graphical syntax which is understandable for all
stakeholders and usable for the engineers.
How the language is implemented depends on the development environment. However, its specification shall provide analyzable models. For EMF-based development
methods this could, for example, be done using XText [Ecl13].
An important aspect of the dependency language is that it improves the comprehension and is accepted by its stakeholders. This must be evaluated by behavior
engineers and all other stakeholders who want to trace the requirements.
3.2.5 Step 5: Conflict Analysis Algorithm Development
Dependency model specifications can contain conflicts. These are dependencies
that cannot be applied together. The method developer can find possible conflicts
through a play-out of every combination. Such combinations might reveal (transitive) patterns. Next, an algorithm that identifies those conflicts must be developed.
This might be possible through OCL-Constraints.
While this application step is not essential to the synthesis, it is required in order
to catch inconsistencies as early as possible.
The completeness of the conflict analysis must be evaluated to ensure that it identifies every conflict. Furthermore, the evaluation must validate that the analysis does
not return false-positives. Otherwise, the process could get stuck at the dependency
specification, because it requires to continue that all conflicts are fixed.
3.2.6 Step 6: Automatic Synthesis Algorithm Development
To develop the synthesis algorithm, the method developer requires for every dependency expressible by the dependency language a semantically equivalent modeling
for Real-Time Statechart. In identifying these modelings, he must be aware that
they must be combinable. As such, he must consider that the synthesis uses limited elements rarely to model a dependency. For example, in Real-Time Statecharts
and Timed Automata, each transition is limited to involve one channel at most.
This means that there can be a trade-off between best-practices and non-blocking
36
modeling used by the algorithm. If no modeling exists that allows independent application, then the synthesis algorithm must catch those dependencies and provide
another modeling. However, it might also be the case that those dependencies are
impossible to combine as they are in conflict, because no valid implementation is
possible.
The method developer should develop a synthesis algorithm – if the language enables this – which combines inter-behaviors and inner-behavior inside separated
compartments. This would preserve the distributed character of the inter-behaviors
and fulfills the requirements of traceability and maintainability. The synthesis algorithm could then, in a second step, weave the dependencies into this intermediate
result. If an independent modeling of all dependencies exists, the algorithm can be
implemented as an incremental transformation. This would even allow the intrabehavior to be extended by additional dependencies without re-synthesizing the
others. Since each dependency leads to further restrictions of the intra-behavior,
the synthesis algorithm should aim to prevent large changes and restructuring of
existing behavioral elements, such that an identification of correspondences by the
behavior engineer is possible even without software-assistance, e.g., transformation
trace information.
Again, whether the complete synthesis algorithm does what it is supposed to, i.e.,
enabling traceability between inter- and intra-behavior, preserving the refinement
relation, and generating a maintainable inter-behavior, needs to be evaluated.
37
4 Application to MechatronicUML
This chapter describes how the synthesis method defined in Chapter 3 is applied
to MechatronicUML. This shall demonstrate the applicability of the synthesis
method and the procedure shown in Figure 3.1. Likewise, it shall assist developers of
software component development methods to integrate the synthesis method. Since
a complete application following the procedure in Figure 3.1 would be beyond the
scope of a master’s thesis, this chapter presents an overview. The most important
parts of the application are included. The omission of others, due to limits on the
time and breadth of this work, will also be explained in this chapter.
In consequence, the most important parts had to be chosen. Figure 4.1 shows the
steps that the thesis’s author decided to cover in color and the steps which remain for
future work in gray. In particular, this decision was done for the following reasons:
Dropping Step 1 was not an option, because all of the following steps depend on it.
Although, Step 2 can be carried out independent of Steps 3-6, this step is indispensable to the demonstration presented here. Study of the old synthesis approach of
Henkler [Hen12] reveals was noticed that Step 3 is essential, because it is necessary
to know all common dependency kinds in order to develop a fitting dependency
language in Step 4. Without a nearly complete set of dependency kinds, the new
dependency language and synthesis might not be suitable for later discovered dependency kinds. Consequently, this would require the reapplication of Steps 4, 5,
and 6. Hence, Step 3 including its evaluation has been applied. For Steps 4, 5,
and 6, it was preferable to complete the dependency language (Step 4 ) instead of
without
auto. synthesis
1
Dependency Language
Development
4
Legend
MUML’s
Process Adaptation
MUML Analysis
Comprehension
artefact
2
Usability + Safety
Conflict Analysis
Correctness +
5
Completeness
process step
Dependency Kind
Analysis
3
User Acceptance
Automatic Synthesis
6
Traceability +
Maintainability +
Refinement
integrated evaluation step
with
auto. synthesis
missing in thesis
Figure 4.1: Applied Parts of the general Procedure
39
4. Application to MechatronicUML
having a completely synthesizable but only partially defined language. Step 5 was
dropped completely, as it is only required to catch erroneous specifications earlier
in the development process. Step 6, was partially omitted due to time constraints.
However, to demonstrate that this idea works, it was halfway implemented. All evaluations Steps, with the exception of Step 3, were dropped because they are likely
too time-intensive for the scope of the current work.
In parallel to the application of the method, this chapter integrates the Railcab
Enter-Section example from Chapter 1 in the steps’ description. The running example helps illustrating the results of Steps 3-6 and demonstrates how the example
can be modeled and synthesized through the new method. All relevant models of
the running example can be found in Appendix A.
Section 4.1 starts with the analysis of MechatronicUML, wherein the thesis’
scope is further circumscribed. Next, Section 4.2 describes the adaptations to
MechatronicUML’s process. Section 4.3 continues with the analysis of MechatronicUML’s dependency kinds including a user acceptance test. Then, Section 4.4 presents a new developed language which enables expressing the important
dependency kinds. Closing the chapter, Section 4.5 describes a partial synthesis algorithm that allows synthesis of two kinds of dependencies. Furthermore, following
each applied step, its utility is discussed.
4.1 Step 1: Method Analysis
The method analysis of MechatronicUML is comprised of two subsections. Section 4.1.1 first analyzes the current situation of MechatronicUML,1 . after which
Section 4.1.2 describes the resulting challenges for the application. This includes a
detailed description of challenges which this thesis tackles and those which remain
for future work.
4.1.1 MechatronicUML’s Situation before this Thesis
In MechatronicUML, the current behavior development already targets an automatic synthesis of component behavior. It uses Giese’s [Gie03] compositional verification approach and separates between inter- and intra-behavior. Furthermore, it
consists of an dependency language and synthesis algorithm from Henkler [Hen12]
which can synthesize a small subset of dependency kinds (see Chapter 5).
Figure 4.2 outlines the current process [BBB+ 12, p.93]. All activities that behavior
engineers must process for the specification of verified component behavior (intrabehavior) are depicted. The process takes the component and protocol roles’ behaviors as input. Both are required in order to specify the ports’ behaviors (4.3.1)
1
MechatronicUML in version 0.3 [BBB+ 12] before the thesis’ synthesis method was applied.
However, the thesis’ implementation is done for version 0.4
40
and the dependencies (4.3.3) in parallel. When this specification is done and the
ports’ behaviors have been verified (4.3.2), automatic synthesis (4.3.4) takes place.
If the automatic synthesis supports all required dependencies and is successful, then
the component behavior specification process is complete. Otherwise, the engineers
must model the intra-behavior completely manually (4.3.5) and verify that it is free
of deadlocks (4.3.6).
Roles‘ behavior described
by Real-Time Statecharts
component
Process: derive
components‘ behavior
(4.3)
Roles‘ behavior
Roles‘ behavior
described by
described by Realcomponent
Real-Time
Time Statecharts
component
Statecharts
specify dependencies between
derive port behavior
component’s roles (4.3.3)
for role (4.3.1)
1.
composition
rules
set of
Real-Time
Statecharts for
port behavior
[refinement
is incorrect]
2.
«datastore»
composition rules
check applicationspecific refinement (4.3.2)
set of Real-Time
Statecharts for port
behavior
[refinement is correct]
composition
rules
set of Real-Time
Statecharts for
port behavior
«datastore»
set of Real-Time
Statecharts for port behavior
3.
automatic synthesis of
synchronized behavior (4.3.4)
set of Real-Time
Statecharts for
port behavior
«optional»
Real-Time
Statechart for
component’s
behavior
[synthesis not possible]
[synthesis successful]
4.
model synchronized
behavior manually (4.3.5)
composition rules
Real-time statechart
that synchronizes the
port statecharts
[deadlocks exist]
«datastore»
Real-Time Statechart
for component’s behavior
6.
check for deadlock
freedom (4.3.6)
[no deadlocks exist]
Orange: Problems of the current process
for component’s
behavior
5.
Real-Time Statechart for
the component‘s behavior
Figure 4.2: The Subprocess to model the Behavior of a Component [BBB+ 12, p.93]
41
The current synthesis integration does exhibit multiple problems. These are marked
in orange in Figure 4.2 and are discussed below.
1. MechatronicUML expects the protocols’ roles to be refined by ports’ behavior (4.3.1), yet the definition of dependencies is based on protocols’ roles
(4.3.3). This makes it impossible to reference states and transitions in dependencies that are introduced during the port refinement. Furthermore, it does
not comply to the development order of Figure 1.4.
2. Two limited composition rule languages by Eckardt and Henkler [EH10] exist
for the specification of dependencies (4.3.3). They do not include data and
are designed for Timed Automata [BY04] instead of Real-Time Statecharts.
Thus, they cover only a subset of dependency kinds. Later, Henkler [Hen12]
translated the composition rules to Real-Time Statecharts, however, this only
changed the syntax slightly, and it did not extend the expressiveness. The first
language allows modeling of state composition rules. These rules can forbid
combinations of states or restrict their active time through timing constraints.
The second language allows modeling of event composition automata. Such automata restrict transitions via additional time constraints, e.g., that a certain
state must be active for 5ms before another can be entered.
Aside from their limited expressiveness, neither composition rule language
has been evaluated for usability and comprehension. One possible drawback
of the event composition automaton by Henkler is that it shares the syntax
of Real-Time Statecharts, but differs in its semantics. This could lead to
confusions. Furthermore, using event composition automata, the specification
of a dependency is quite large in relation to its informal requirement and could
reach the size of the final intra-behavior. There might also be a wide gap
between the informal requirement of a natural language and its representation
as an automaton. Additionally, it does not fulfill the expected analyzability.
A detailed description can be found in the related work (see Section 5.1).
It is the author’s opinion that the aforementioned drawbacks make composition
rule languages inappropriate for use as dependency languages. They must
either be extended or replaced.
3. Eckardt and Henkler [EH10] have further developed an automatic synthesis
among Timed Automata. This was also translated by Henkler to Real-Time
Statechart. It combines all inter-behaviors of one component to a centralized
intra-behavior and refines this with respect to both composition rule models.
However, the reuse of their synthesis is not possible for the following reasons:
• The approach generates a complex centralized Real-Time Statechart by
building a cross product of all ports’ inter-behaviors, which is modified
through the application of the composition rules. This distributes a single
state of an inter-behavior over several states. This way, the maintainability and traceability of the synthesis’ resulting intra-behavior is highly limited. However, we need to manually adapt the intra-behavior as long as
42
not all dependencies can be automatically synthesized. Whether a complete automatic synthesis is ever possible to implement is questionable.
This must be evaluated in future work. Besides, good maintainability is
crucial to debugging.
• A centralized synthesis prevents a concurrent execution. That is, Eckardt
and Henkler’s synthesis only allows a sequential combination of all interbehaviors. At the moment, this would be sufficient for MechatronicUML because it currently only allows a sequential execution of components. However, future support for parallel execution is planned. As
such, the synthesis should preserve the distributed character of the interbehaviors.
• The synthesis algorithm of Henkler [Hen12] does not synthesize all kinds
of dependencies which can exist between Real-Time Statecharts, such
as data, concurrency, and synchronization channels. Thus, not only does
Eckardt and Henkler’s dependency language have its drawback (see point
two), but the synthesis algorithm is also incomplete. For example, Figure 4.3 shows a switch containing four ports. Three ports (left, right,
bottom) implement a refinement (see Section A.2.4) of the section role of
the EnterSection protocol. The followingSection port refines the role of
the NextSection protocol (see Section A.2.1). The followingSection port
provides data if the section is free. This data is required in all ports that
use the EnterSection protocol(see blue arrow in Figure 4.3). Furthermore,
the switch only permits one RailCab at a time (see red arrow). These
kinds of dependencies are unsupported or only partially2 supported by
Eckardt and Henkler’s approach.
followingSection
Switch
left
Data Transfer
XOR
bottom
right
Figure 4.3: Dependency between the Switch’s Ports
Besides, the process does not consider that the composition rules may contain
conflicts, i.e., a transition back to activity (4.3.3) is missing in Figure 4.2.
4. In the case that the synthesis proves to be impossible, the process does not
reuse the automatically synthesized Real-Time Statechart, and the entire synthesis must be carried out manually. However, that is automatically implied
when not all dependencies are explicitly specifiable. This deviates from the
process in Figure 1.4, which requires that the synthesis result be used as the
basis for manual adaptation, even if not all dependencies were explicitly specifiable or synthesizeable.
2
The exclusion of state combinations is possible, but only for a sequential result.
43
5. The intra-behavior development process finishes if the synthesis is successful. However, the synthesis might be faulty or has produced a intra-behavior
that includes deadlocks. This is not checked and so the intra-behavior is not
verified. Here, Figure 1.4 specifies a refinement check for step three.
6. The manual specification of dependencies also potentially destroys the refinement relation. There is no difference in the scope of possible failures when
compared to the automatic synthesis. As such, the verification must include
a refinement check, as illustrated in step four of Figure 1.4. A check for deadlocks is not sufficient.
In any case, the current implementation of MechatronicUML no longer supports
the outdated implementation of the composition rule language and synthesis. As
such, a new / adapted implementation is required any way. This facilitated the
decision to start from scratch.
4.1.2 Application Challenges
The analysis has shown that none of the Steps 2 to 6 shown in Figure 3.1 have
already been designed sufficiently. Hence, the development order and activities of
Figure 1.4 are not fully supported by MechatronicUML. To amend this, the
following challenges are solved in this thesis:
Step 2: Process Adaption As previously shown, the current process is not fully
suitable for the thesis’ method. It needs adaptation. This is described in
Section 4.2.
Step 3: Dependency Kind Analysis Currently, Eckardt and Henkler’s work [EH10]
offers a language that consists of two kinds of composition rules. These have
been developed from the need to express certain dependencies. They never
analyzed what kinds can exist. This analysis is difficult because it requires
representative and quantitative models from real projects or significant expertise. For MechatronicUML, the set of intra-behavior models is small.
This makes it especially difficult to validate that all important dependency
kinds are found. Nevertheless, this thesis provides a detailed analysis using
the expertise of developers and a small set of models (see Appendix A) in
Section 4.3. Furthermore, it evaluates the identified dependency kinds on the
basis of frequency.
Step 4: Dependency Language Development MechatronicUML needs a new
dependency language. This must include all common dependency kinds identified in Step 3. It should allow easily understandable specification of dependencies, such that all stakeholders are capable of understanding them. The
new language, including examples how to model dependencies, is described in
Section 4.4.
44
Step 6: Automatic Synthesis Algorithm MechatronicUML also requires a new
synthesis algorithm that allows synthesis of all dependency kinds specifiable
by the dependency language defined in Step 4.
The synthesis algorithm shall allow incremental dependency specification. So,
the syntheses shall not destroy the structure and not change the names of
states. Additionally, the syntheses of dependencies shall be mostly independently combinable without risking conflicts. These requirements limit the
possibilities to synthesize dependencies, which complicates the synthesis algorithm’s development.
The development of such a synthesis algorithm is very time-consuming. As
a result, this thesis includes only a partial implementation. It concentrates
on the first part of the algorithm development, namely, the specification of
transformations that synthesize each dependency in isolation from other dependencies. Appendix B describes possible syntheses for all dependency kinds.
The activity (4.3.4) from Figure 4.4 abstractly presents how the implementation is done. More details of the new implementation and its concept are
described in Section 4.5.
The previous challenges are covered in this thesis, with the exception of the implementation of the synthesis algorithm. The synthesis algorithm for isolated dependencies will only be partially implemented due to time limitations. It will be able to
synthesize several dependency kinds. The remainder must be implemented in future
work. Furthermore, several other challenges are future work:
Step 5: Conflicting Dependencies Dependencies can be in conflict, i.e., one dependency specifies that a certain state combination is required to enable transitions while another forbids this exact combination. Accordingly, the task is
to identify all possible sources of conflicts. Possible sources of conflicts can
be due to dependency languages semantics but also due to the synthesis algorithm implementation. For example, if the algorithm maps dependencies to
multiple channels at one transition. Furthermore, a dependency kind could be
limited, e.g., by the number of execution branches or states.
It must be further evaluated whether some of those conflicts could be resolved
during the automatic synthesis. Otherwise, those conflicts must be caught
during the automatic synthesis or before. The optimal position in the process
for the identification of all conflicts must be determined, such that conflict
detection could be done in optimal time. There probably exist conflicts that
are as time-consuming to automatically detect as an automatic synthesis. As
such, it makes sense to split the conflict detection into multiple parts, as does
the process presented in Figure 4.4. Finally, an analysis algorithm that can
detect all conflicts is required.
Step 6: Synthesis of all Dependency Combinations The synthesis algorithm
must be completed such that it supports synthesis of any combination of dependencies. Its difficulty may be greater in relation to the synthesis of depen-
45
dencies in isolation. Synthesizing multiple dependencies may require a certain
application order. For example, merging variables or clocks may change elements’ names and positions, which can then require that they be applied
towards the end of the sequence such that element references of other dependencies are not broken. Some dependencies might even need to be processed
in combination, i.e., not in isolation, because their isolated application would
lead to a conflict (see Step 5 ).
As previously mentioned, the preservation of structure is expected to allow
most dependencies to be applied independent of others. Nevertheless, whether
it is always possible to synthesize the intra-behavior and how the final synthesis
must work remains unanswered.
Step 6 Evaluation: Preserve Refinement The synthesized Real-Time Statechart
must preserve all verified properties of its ports. The challenge is to build a
synthesis algorithm that always refines the behavior. However, this requires a
sophisticated formal proof.
For the algorithm’s validation, Eckardt and Henkler’s [EH10] proof could probably be reused. They proved the refinement relation (conformance) of their
synthesis’ result, showing that a refining solution exists for all dependencies
expressible by composition rules (see Table 4.1). Their proof may further be
used for the dependency kinds which are similar to these dependencies, e.g.,
clock and data constraints.
The formal validation might show that dependencies could in some situations
or even always destroy the refinement definition. For example, data assignments and clock resets may lead to behavior that was previously impossible,
e.g., guards become satisfiable which have been unsatisfiable before. Whether
they always destroy the refinement must be determined. Nevertheless, the
thesis’ author recommends inclusion of dependency kinds that allow changes
to clocks and data values, because they are required in several cases. To guarantee valid behavior, it is important that the new process (see Figure 4.4)
includes a refinement check following the synthesis process.
Detailed Evaluation of the Synthesis Method The synthesis method is partially
evaluated, limited to the identified dependency kinds. A detailed evaluation
of the improved process, dependency language, and the synthesis algorithm
should initially be carried out on small examples and later on industrial examples. This evaluation will show whether the new approach improves on the
previous state of development.
46
4.2 Step 2: Process Adaptation
This section describes how MechatronicUML’s process is modified to be in compliance with the synthesis method of Figure 1.4. To achieve this, it must fix the
previously mentioned problems (compare Figure 4.2) and meet the defined requirements. Figure 4.4 illustrates the new process. Its differences to the original are
numbered and highlighted in blue and in bold type.
Roles‘ behavior described
by Real-Time Statecharts
component
requirements
1.
Process: derive
components‘ behavior
(4.3)
derive port behavior
for each role (4.3.1)
2.
3.
[refinement incorrect]
«datastore»
Set of Real-Time
Statecharts for port behavior
«optional»
specify inner-behavior
(4.3.2b)
check applicationspecific refinement (4.3.2)
[refinement correct]
6.
Specify state-aware
dependencies between
ports’ behaviors (4.3.3)
5.
«datastore»
Set of Dependencies
7.
[conflict]
conflict analysis of
dependency model (4.3.3b)
4.
[no conflicts]
«datastore»
for inner-behavior
8.
merge ports’ behaviors into concurrent regions of single RTSC
Real-Time Statechart for component’s
behavior with independent regions
[conflict]
9.
weave dependencies into component’s behavior
[no conflicts]
automatic synthesis of synchronized behavior (4.3.4)
«datastore»
for component’s behavior
10.
[synthesis incorrect]
refinement & deadlock check
(4.3.6)
11.
[else]
integrate dependencies manually
into component’s behavior (4.3.5)
[verified]
[synthesis insufficient]
Blue / Bold: changes to activity / data / process flow
Real-Time Statechart for
the component‘s behavior
Figure 4.4: Modified Subprocess to model Component’s Behavior [BBB+ 12, cf. p.93]
47
Each difference is elucidated in the following enumeration:
1. All specifications depend on requirements. Thus, the requirements are included as an additional input. They include specifications for the concrete
modeling of inter-behaviors, inner-behavior, and dependencies. For example, they could specify top-level component states that involve more than one
inter-behavior, such as an idle state. They could also specify forbidden state
combination forbidden. However, the manner by which the requirements are
specified (informally or formally) is not important for this work. For example,
some message sequence dependencies can already be specified inside Model
Sequence Diagrams.
2. The specification of port behavior (4.3.1) now includes a data input from
the application-specific refinement check (4.3.2). This should illustrate that
the refinement check can provide counterexamples in the form of refinement
violations. These counterexamples enable a better debugging in case the refinement was incorrect, e.g., using the approach of Gerking [Ger13]. The input
is nonessential for (4.3.1); it should only help to create a correct refinement.
3. Inner-Behavior was previously impossible to specify when the automatic synthesis was used, except in the manual modeling of dependencies. The new
parallel activity (4.3.2b) enables specification of an additional Real-Time Statechart that includes operations, calculations, and states that might depend on
several inter-behaviors. For example, it allows the specification of complex
states which can later be synchronized with the dependent inter-behaviors.
Furthermore, it can be used to encode high-level System States of the requirements. This can improve the comprehensibility and reduce the complexity
of dependency constraints. It might even be useful to circumvent that some
dependencies may not be expressible between inter-behaviors directly.
4. The inner-behavior is now stored independently of the synthesized component’s behavior and is used as an input for the dependency specification and
the synthesis. This was not possible in the old process.
5. A new dependency model replaces the old composition rules. Now a behavior
engineer can specify all common dependencies before the automatic syntheses
instead of only a partial set, including, e.g., data dependencies.
6. The specification of dependencies is carried out using the new dependency
language of Section 4.4. Dependencies are specified state-aware between interbehaviors and optional between inner-behavior. This requires that the specification is no longer parallel to the port behavior specification (4.3.1). It
must occur in sequence following (4.3.2) and (4.3.2b). The term ‘state-aware’
should clarify that the dependencies are not specified as message sequences,
but as a more specific and compact kind that enables the referencing of states
and transitions. The author assumes, all message-aware dependencies can be
transformed into one or more state-aware dependencies. The details of the
differences are given in Section 4.4.1.
48
Further, the activity includes an input that provides information for debugging. This is provided to fix the specified dependencies if a conflict or an
incorrect refinement is determined.
7. The combination of dependencies could be conflicting, i.e., their combined application may be in contradiction and lead to unfulfillable constraints. This activity step makes possible the detection of conflicts for which it is semantically
simple and also does not depend on the synthesis algorithms implementation.
For example, a dependency could specify that a transition requires that a certain state to be inactive. Another could specify the opposite. This would be an
obvious conflict, but transitive conflicts that require more complex detection
rules are also possible.
Nevertheless, there may also be conflicts present, the identification of which
creates more difficulty prior to as opposed to integrated in automatic synthesis.
For example, this could occur if combinations led to unreachable states, which
were required to be accessible, which is why those are ignored in this step and
their identification is postponed to the automatic synthesis.
This activity might also be superfluous, as the conflicts may be catchable during the dependency specification (4.3.3) through static-semantic check using
OCL-Constraints. The step’s existence must therefore be evaluated. However,
it might also provide useful insight into the process, in that each specification
step is followed by a verification.
8. This activity is the first part of the automatic synthesis (4.3.4). It uses the
Real-Time Statechart of inter-behaviors and inner-behaviors to create the component behavior. The created component behavior merges the inter-behaviors
and inner-behavior into concurrent regions. The new synthesis handles all
specified inputs of those two behavioral inputs, including hierarchy, data, and
concurrency.
Using regions changes the synthesis algorithm from its current character centralized to distributed. The creation of the component behavior can be accomplished through model transformations (see Section 2.4). The result is an
intermediate intra-behavior which does not include any dependency. Thus, its
top-level regions are independent. Section 4.5 describes further details of the
new automatic synthesis.
9. This activity is the second part of the automatic synthesis (4.3.4). It restricts the intermediate intra-behavior according to the dependencies specified
in the dependency model. Thereby, it has to preserve traceability and humanreadability. During this step, it is possible that a dependency application fail
due to a conflict, in which case, the synthesis would stop and pass the conflicting dependencies’ information back to the dependency specification activity
(4.3.3). Otherwise, the automatic synthesis is carried out and the process
continues with a verification.
49
10. The activity (4.3.6) no longer consists of a plain deadlock check; it now additionally includes a refinement check. The activity shall guarantee that the
intra-behavior is a refinement of its ports (see Section 2.6.3) and that it is not
so far restricted to the point that deadlocks become possible. This activity is
important for the verification of manual adaptations (4.3.5) because those can
hardly be limited to valid actions. However, the automatic synthesis (4.3.4)
might also produce intra-behaviors which violate the refinement, e.g., through
global clocks. These must be caught. Identification of these violations earlier
in the process might not be possible because of their dependence to the implementation of the automatic synthesis’ algorithm or could be more computation
intensive as if the automatic synthesis is done before.
Additionally, the refinement check is useful for identifying incorrect implementations of the automatic synthesis. A determined violation can reflect either a
failure of the synthesis algorithm, the refinement check, or an invalid dependency. If this occurs, those two automatic steps can cross-verify themselves.
11. The manual adaptation (4.3.5) of the synthesized Real-Time Statechart shall
enable the specification of dependencies which have been ignored on purpose
in the dependency language and automatic synthesis due to their unimportance. In comparison to the old process (see Figure 4.2), the synthesized
intra-behavior is now used as a foundation. This reuse is made possible only
by its human-readable structure. Besides, it is required in case some dependency kinds have not been identified or the implementation is incomplete (as
it is in this thesis).
As this set of process adaptations illustrate, this second method application step
could alter the behavior specification process considerably. Nevertheless, most
changes are just a consequence of the previous method analysis. As such, this
step took the least time of all applied steps. However, the evaluation might change
the proportional effort.
Without an evaluation, the new process can hardly be validated as an improvement.
However, the author expects the new process to be an improvement and its application to result in a verified component’s behavior. The process’ analysis activities
shall catch errors earlier, and now counterexamples of these are also illustrated to be
usable during debugging. Furthermore, through a more expressive dependency specification, its development cycles shall be reduced because fewer error-prone manual
adaptations must be done. The process shall also reduce the effort required when
an inter-behavior changes. Most involved dependencies are now declared together
in one compact model to be fixed more easily. Additionally, the structure preservation and the dependency model shall provide a new level of traceability. The more
powerful automatic synthesis further reduces the variations of dependency implementations. Thus, the intra-behaviors’ quality depends less on behavior engineers
and should therefore generally increase.
50
4.3 Step 3: Dependency Kind Analysis
Initially, separation of dependencies can be done on an abstract level, independent of
MechatronicUML. Some dependencies are message-aware and others are stateaware. The former only enable the specification of message sequences. They receive
no information about state-based protocol’ and port’ elements. Typically, they
result from requirement engineering or from a refinement of those requirements.
They are also commonly early specifications, since they do not reference any states.
In contrast, the state-aware dependencies are familiar with the state-based behavior
of ports, and enable the specification of dependencies for states and transitions.
Therefore, these must be specified after the state-based port behavior design. The
following will focus on state-aware dependencies because their diversity is much
higher. Another reason is their higher likelihood of being used to describe most
dependencies of state-based behavior due to their greater precision and compactness
than most message-aware dependencies.
As mentioned before, in MechatronicUML, a component typically contains innerbehavior and several ports. Each port contains a refined protocol role behavior. In
one component, its ports interact directly or mediated by an inner-behavior. The
component behavior is defined within one Real-Time Statechart containing one state
that is always active, and this state contains one region for each port, along with
regions for inner-behavior. Furthermore, it contains dependencies between different
regions, such as data transport or synchronization.
In this section, the thesis performs an analysis of the aforementioned dependency
kinds, starting with Section 4.3.1, wherein the requirements for dependencies are
described. Knowing the requirements of dependencies allows analysis of existing
MechatronicUML projects. Only flat regions are considered in the analysis for
the sake of simplicity; whether hierarchy influences the number of dependency kinds
must be investigated in future work. In Section 4.3.2, the results of the analysis
are collected into a catalog of possible dependency kinds. The catalog does not
aspire to completeness, but seeks to include the most important and plausible kinds
which are needed for real projects. The reasons for this are described in Chapter 3.
Afterwards, the identified dependency kinds are further categorized in Section 4.3.3.
Section 4.3.4 then provides a brief analysis of possible dependency combinations and
conflicts. Section 4.3.5 shows some dependencies of the running example in detail.
Thereafter, Section 4.3.6 evaluates the collection, to find dependency kinds which
are either implausible or were previously not considered. Section 4.3.7 finishes with
a summary and discussion of application Step 3. The new dependency kind catalog
builds the base for the dependency language discussed in Section 4.4.
4.3.1 Requirements for Dependencies
For the presence of dependencies, a component Real-Time Statechart is required to
have at least two regions, e.g., two ports or one port and an inner Real-Time Statechart for calculations. Many different elements exist within Real-Time Statecharts
51
(see Section 2.8.2.2). As dependencies require that two regions be involved, it is
necessary to focus on elements that can be shared / accessed by multiple regions.
This makes it possible to drop guards, actions, messages, transitions, and states.
Operations can be globalized. However, their results only depend on the variables
provided via parameters. They are unable to store data from previous executions.
Thus, they can be dropped them as well. This leaves only three remaining kinds of
elements that can be used for the implementation of dependencies between regions:
channels, clocks, and variables.
As a consequence of these conditions, Real-Time Statecharts with dependencies
require that at least one of the three kinds be declared internally. In particular,
these must be shared between regions by declaring them in a common ascendant
state or statechart. Furthermore, they must been used in at least two regions. The
elements can be employed within guards and invariants of transitions and states.
Shared data can additionally be employed in actions, messages, and operations.
4.3.2 Catalog of MUML’s Dependency Kinds
This section is the product of intensive syntax analysis, discussions with Stefan
Dziwok (the thesis’ advisor), and analysis of existing projects. However, it describes
only an excerpt—five of the dependency kinds identified by this thesis—to provide
an impression of what kinds of dependencies exist. The complete catalog contains 21
dependency kinds, which can be found in Appendix B. The catalog’s dependencies
are structured like patterns, because they describe how reoccurring requirements
(problems) can be solved.
With respect to the upcoming dependency kinds, it is a critical requirement that
dependencies always require at least two involved regions. Because even if the
description would fit with only one region, this would not be a dependency without a
second involved region. Additionally, if a dependency kind affects a transition, it can
also be commonly used for a set of transitions, e.g., all outgoing transitions from one
state. This must also be considered in the language specification of Section 4.4.
Note that when the term event is used in this section, the following is meant: the
deactivation or activation of a state (combination), or a transition execution. Furthermore, in every Real-Time Statechart example, the color green denotes that elements which are introduced to implement the dependency while red denotes those
elements which must be removed.
The next paragraphs describe the following selected dependency kinds, including an
abstract exemplary implementation:
(1) Enforced Transition Combination
(2) Required Change Event Constraint
(6) State Space Limitation
52
(10) Data Assignment
(11) Data Constraint
Track
channel: sync;
left
Idle
sync!
request
1
2
Check
Request
1
followingSection
Idle
sync?
/ request()
1
Waiting
Answer
Figure 4.5: Example Synthesis of Enforced Transition Combination
1) Enforced Transition Combination It could be that two transitions or states
need be executed synchronously. To this end, the enforcement of transition combinations must be enabled. Such a combination restricts the referenced transitions such
that they cannot be executed by themselves. Thus, the conditions of all transitions
must be satisfied before they can be executed.
The following requirement is one such dependency:
A normal track passes the railcab’s requests synchronously to the following section.
In a Real-Time Statechart, the synchronous communication uses channels. Hence,
during the synthesis, this requirement could be modeled as shown in Figure 4.5.
2) Required Change Event Constraint Another dependency kind is the Required
Change Event Constraint. A transition could depend on a certain change event
happening. By change event, any of the following one is meant: transition triggering,
state (combination) entering, and state (combination) exiting. The State-Do-Event
is not considered a change event, as it does not change the state.
Through the Required Change Event Constraint, it becomes possible to enable or
disable transitions when the specified change event occurs. Its effect could then be
inversed through another change event. This allows to specify an event constrained
interval in which a transition is allowed to be executed.
The following requirement is one such dependency:
When a track receives a request from a railcab, it is allowed to forward the request
to the following section. Furthermore, it is not allowed to process incoming requests
of other sections until the request check is finished.
The term constraint should emphasize that the dependency kind leads to restriction
of transitions specified in guards. So, this requirement could be synthesized as
shown in Figure 4.6. A variable is used to indicate whether the required event
occurred. This variable enables or disables the transitions of the following section.
It is inversed when the CheckRequest state is left.
53
var: bool flag:=false;
Track
request
/ {flag:=true;}
right
1
Idle
2
2
1
CheckRequest
Exit/{flag:=false;}
Approved
1
followingSection
[flag] / request()
1
Idle
2
[not flag]
request
1
Waiting
Answer
Incoming
Request
Figure 4.6: Example Synthesis of Required Change Event Constraint
The Required Change Event Constraint can specify many different dependencies
because it freely allows specification whenever the constraint gets inversed. However,
it is possible to determine several typical sub-kinds which use predefined pairs of
events to specify a time interval. Those sub-kinds can be found in the Appendix B.
Their main advantage is that their coupling of events allows them to be expressed
using abbreviated notation.
6) State Space Limitation State Space Limitations are crucial to prevent unwanted behavior such as hazardous situations. These can be specified in two ways:
Through the definition of (6a) Forbidden State Combination which reduces the
global state space, or through the specification of (6b) Allowed State Combination
which spans a partial state space, starting from zero. The first can be compared with
a black list and the second with a white list specification of state combinations.
Such a Limitation can specify that certain region’s states mutually exclude each
other. For example, we could have the following requirement:
A section of track must not admit entrance to itself from both sides simultaneously.
This requirement could be synthesized as depicted in Figure 4.7. It reduces the
state space through an auxiliary region which prevents the states of the forbidden
combination from becoming active at the same time.
10) Data Assignment In components, it is necessary to transport and process
data. For example, a converter accepts data from one port, process it, then sends it
via another port. Such data transport is possible through assignments. Assignments
allow the transport of data from variables of one region to another region. These
assignments could include transformations, e.g., for measurement entity adaptation.
There are two ways to transfer data with assignments: read other regions’ variables
((10a) Data Pull) or write on other regions’ variables ((10b) Data Push).
54
Track
channel: enter, leave;
3
ForbiddenStateProtection
1
enter?
Vacant
Occupied
1
leave?
2
left
Check
Request
1
Check
Request
1
enter!
EnterAllowed
leave!
1
1
right
enter!
EnterAllowed
leave!
1
Figure 4.7: Example Synthesis of State Space Limitation
A requirement could be:
A railcab is allowed to drive 80km/h alone, whereas in a convoy, the railcabs are
allowed to drive 80km/h plus 10km/h for each railcab include in the convoy, because
they profit from the slipstream. The maximum speed limit is 160km/h.
This could be synthesized as illustrated in Figure 4.8. The used variable is promoted
to global scope. This change allows it to be used in the assignment of the drive
section, here it is read.
var: int convoyMembers;
RailCab
op: min(int a, int b); var: int speedLimit; 2
drive
1
Driving
/ {speedLimit:= min(160,
80+10*convoyMembers)}
var: int convoyMembers; 1
master
1
/ {convoyMembers--;}
Convoy
2
Figure 4.8: Example Synthesis of Data Assignment
11) Data Constraint Data from one region could be used as guards in other
regions. Data constraints do not exchange data over regions in the manner that
(10) Data Assignment and (9) Data Merge do. They are only used to restrict the
behavior of one region on the basis of another region’s data.
55
A requirement could be:
The RailCab relies on the GPS and SpeedSensor if their values differ by more than
5 km/h to calculate the speed, otherwise it only relies on the SpeedSensor data.
This could be synthesized as depicted in Figure 4.9. The state change of the SensorMode depends on the values of two other regions. It uses the speed values to
determine whether the difference between both sensors is within tolerance. The
required adaptation of the Real-Time Statechart is similar to the (10a) Data Pull,
but because the data constraint only has influence on transition executions but no
influence on data variables, they are considered separately.
var: int calculatedSpeed, int measuredSpeed;
RailCab
op: abs(int a); 3
[abs(calculatedSpeed –
measuredSpeed) <= 5]
Sensor 1
Sensor
+
Only
1
GPS
measuredSpeed) > 5]
GPS
var: int calculatedSpeed 2
SensorMode
SpeedSensor
var: int measuredSpeed 1
Figure 4.9: Example Synthesis of Data Constraint
4.3.3 Categorization of Depedency Kinds
During the analysis, fourteen dependency kinds along with eight sub-kinds were
found. By sub-kinds, the dependecy kinds denoted by with an additional letter
after their number are meant. In the cases of (2) and (10) in Table 4.1, those subkinds are dependency kinds which could all have been expressed by their containing
dependency kind. The sub-kinds of (10) map the complete range of Data Assignment. Thus, the Data Assignment is only a grouping. Whereas the sub-kinds of
(2) do not map the full expressiveness, they only indicate common usages of the
containing dependency kind. There are also the sub-kinds of (6) and (7), which do
not partition its containing dependency kind, but rather are alternatives to specify
its containing dependency kind.
The fourteen dependency kinds can be further clustered. Every dependency kind
that specifies a constraint (indicated by its name) could be applied to the same kinds
of targets. As such, we can group them as Constraint Dependencies. Additionally,
we can append the group by (5) Access-/ Leave-Counter Limitation because it is
an extension of (2) Required Change Event Constraint. This grouping reduces the
top-level dependency kinds from 14 to 9. As a result the dependency kinds become
a bit more manageable for the language development, i.e, commonalities only need
to be specified once for all sub-kinds.
56
Furthermore, we could cluster the dependency kinds through their characteristics,
e.g., time, data, etc. Table 4.1 provides an overview of all dependency kinds including their characteristics, like the involved syntax elements and their dependency
direction. For example, (1) Enforced Transition Combination partially involves time
because it requires a synchronicity and it can couple transitions and even complete
states. Although not shown in this table, all but two of the dependencies (Data
Merge and Clock Merge) involve ar least one transition. It was more important
to display a column showing which dependencies involve more than one transition.
Thereby, it outlines which dependencies can reference more than the target transition (directly or indirectly by messages, events, etc.).
1) Enforced Transition Combination
2) Required Change Event Constraint
2a) Required State Constraint
2b) Once Required State Constraint
2c) Required Transition Constraint
2d) Once Required Transition Constraint
3) Message Sequence Constraint
4) Entry- and Exit-Clock Constraint
5) Access- / Leave-Counter Limitation
6) State Space Limitation
6a) Forbidden State Combination
6b) Allowed State Combination
7) Message Sequence Limitation
7a) Forbidden Message Sequence
7b) Allowed Message Sequence
8) Bounded Active State
9) Data Merge2
10) Data Assignment2
2
10a) Data Pull
10b) Conditional Data Push2
11) Data Constraint
12) Clock Merge2
2
13) Conditional Clock Remote Reset
14) Clock Constraint
1
2
involved elements
covered by Comp. Rules
Data Time Transition State Mes.-Seq. Direction State Comp. Event Comp.
-1
-1
o
x
o
o
bi
x
x
o
uni
(-)
x
uni
(-)
x
uni
(-)
x
o
uni
(-)
x
o
uni
(-)
o
o
x
uni
o
x
o
o
o
uni
(-)
o
o
o
uni
(-)
x
x
bi
x
x
x
bi
x
x
x
bi
(-)
o
x
o
x
bi
x
o
x
o
x
bi
x
o
x
o
x
bi
(-)
o
o
o
x
o
uni
o
(-)
x
bi
x
uni
x
uni
x
o
o
o
o
uni
x
uni
x
bi
o
x
o
o
o
uni
x
uni
(-)
Eckardt's and Henkler's using a sequential synthesis. This makes parallel constraints unnecessary.
These dependencies may corupt the refinement. It influences verified properties of clocks or data.
o
x
(-)
partially (supported)
involved / supported
uninvolved / unsupported
indirectly supported
Table 4.1: Overview of dependency kinds including involved elements, direction and
the support by Eckardt and Henkler’s composition rules
Table 4.1 also shows that most dependency kinds are unidirectional. That is because
most define restrictions of single states or transitions. Thus, they do not affect multiple regions unless they are combined with one another. Bi-directionality originates
from dependency kinds that use state combinations, synchronizations, or merged
data or clocks.
The two rightmost columns Table 4.1 show which dependency kinds are already
supported by the existing dependency languages (composition rules) of Eckardt and
57
Henkler. The table depicts that they only cover a few dependency kinds completely,
mostly due to the fact that they did not consider data. The state composition rules
only allow the specification of time-bounded active states or forbidden states. The
event composition rules allow restrictions of message sequences. Because almost
every transition contains an receiving or sending message expression, this constraint
can be used to specify the dependencies (2) through (5) and (8). However, such
specification can even become as large as the synthesis’ resulting behavior because
it does not allow reference to transition or states. This makes the event composition
rules mostly impracticable for the specification of dependencies. More details on the
composition rules and Eckardt and Henkler’s work are given in Section 5.1.
4.3.4 Combinations of Dependencies
The catalog’s dependency kinds can be used individually, however, it is also possible
to combined them. Here, we can separate between dependencies which should never
be combined, dependency combinations which often leads to conflicts and therefore should be identified at activity (4.3.3b), shown in Figure 4.4 on page 47, and
combinations which are commonly unproblematic.
Forbidden The dependency kinds (6) State Space Limitation and (7) Message Sequence Limitation each be expressed as on of their two sub-kinds (e.g., (7a)
Forbidden Message Sequence, (7b) Allowed Message Sequence). In both cases,
the two sub-kinds are mutually exclusive. It is only possible to use either black
list (e.g., (6a) Forbidden State Combination) or white list(e.g., (6b) Allowed
State Combination), never both.
Mostly Conflicting The combination of dependency kinds (6) State Space Limitation, (7) Message Sequence Limitation, and (1) Enforced Transition Combination is highly constrained. In the presented synthesis example all three
kinds use channels. Because each transition is limited to the use of only one
channel, the potential for conflict is high. Thus, those dependency kinds must
be used carefully, and may require a different synthesis implementation to be
combined conflict-free. Currently, (6) State Space Limitations are expected
to be synthesizable by fewer channels than (7) Message Sequence Limitation.
Consequently, they should be preferred, such that fewer conflicts will occur
with (1) Enforced Transition Combination.
Rarely Conflicting All constraint dependencies influence guards or invariants. Their
combination via or and and expressions should be possible in most cases. Dependency kinds not namely mentioned here can also be combined. If dependencies are not explicitly concatenated via or, it is expected that they must
all hold and so are concatenated with and. Their combinations may lead to
conflicts when the whole expression is contradicted. For example, a state combination could be forbidden and another guard could require this exact combination. A second example is the case in which two clock constraints lead
to an empty time interval. These conflicts could lead to unreachable states
58
or even prevent all transitions from activating. This work expects that those
dependency kinds are, in most cases, conflict-free. Nevertheless, a detailed
analysis of conflicts needs to be carried out in future work.
Another issue is the possibility that certain combinations can produce deadlocks,
which should be caught by activity (4.3.6) of Figure 4.4. How often deadlocks
occur mostly depends on the dependency directions. As the number of existing
circular combinations or bidirectional dependencies increases, so does the probability
of a deadlock occurring. However, unidirectional dependencies can also lead to
deadlocks, e.g, if they permanently restrict transitions. Obviously, if there are only
dependencies in one direction, the independent regions will not end in a deadlock.
4.3.5 Running Example: Dependency Analysis of Track
This section presents the Normal Track Section of the running example and shows
how a whole component behavior can look like. As a section, the Normal Track
Section has the dependency that only one railcab at a time is allowed to enter the
track (see Figure 1.1 on page 1). Furthermore, the Normal Track Section shall
answer requests from the preceding Switch if the section is free. Figure 4.10 (on
page 60) provides an overview of the manually synthesized behavior. All elements
highlighted in green had to be added to model those dependencies. The elements
highlighted in red had to be removed.
Comparing those elements with the catalog, the dependency kinds (1) Enforced
Transition Combination and (10) Data Assignment can be identified. There are
two new channels for synchronization, i.e, two dependencies of (1) Enforced Transition Combination. Furthermore, the manually synthesized behavior contains five
new assignments of a shared variable, which implies five dependencies of (10) Data
Assignment.
The Normal Track Section proves that at least those two dependencies are already
used. However, the free variables and the Data Assignment dependencies could be
substituted through multiple dependencies of (2) Required Change Event Constraint
or (11) Data Constraint also the Data Assignments could be replaced by one Data
Merge, because there is only one region that is actually writing on the variable. Furthermore, it would be possible to substitute the Enforced Transition Combinations
with a Forbidden State Combination (see (6) State Space Limitation) if the Forbidden State Combination would allow the introduction of a variable that is accessible
for other dependencies. In particular, it would require that the states EnterAllowed,
RailCabOnSection, and WaitPostAction of the left region and the right region be hierarchically composed and then its combination could be forbidden. In this way, the
running example demonstrates that a requirement can be implemented in multiple
ways.
59
NormalTrackSection
variable boolean sectionFree
Top State
ch: acquire, release
variable boolean free
clock c1
RailCabApproaching
c1 ≤ 1800ms
left
Idle
/ newSection() {reset: c1}
[c1 ≥ 1s] [not free] /
{free := sectionFree}
request /
[not free] /
CheckRequest
enterDenied() c1 ≤ 1980ms
{reset: c1}
[free] acquire! /
enterAllowed() {reset: c1}
[free] acquire! /
enterAllowed()
EnterAllowed
{reset: c1}
c1 ≤ 120040ms
EnterDenied
c1 ≤ 1980ms
[c1 ≥ 1s]
release! /
WaitPostAction
c1 ≤ 1s
leaveSection /
confirmExit() {reset: c1}
enterSection /
confirmEntry()
RailCabOnSection
clock c2
right
Idle
RailCabApproaching
c2 ≤ 1800ms
request /
[not free] /
CheckRequest
{reset: c2}
[free] acquire! /
[free] acquire! /
enterAllowed()
EnterAllowed
{reset: c2}
c2 ≤ 120040ms
EnterDenied
c2 ≤ 1980ms
[c2 ≥ 1s]
release! /
WaitPostAction
c2 ≤ 1s
leaveSection /
precedingSwitch
requestSectionStatus /
{reset: c3}
Idle
enterSection /
confirmEntry()
RailCabOnSection
clock c3
Request
Inv: c3<= 500ms
entry /{free:= sectionFree;}
[c3 >= 400ms] /
sectionStatus(free)
internal_behavior
acquire? /
{sectionFree := false}
Free
Occupied
release? /
{sectionFree := true}
Figure 4.10: Component Behavior of Normal Track Section
60
4.3.6 Evaluation
The previously collected dependency kinds must be evaluated for plausibility and
importance. Therefore, we evaluate them through a survey and an analysis of existing models. For the evaluation, this work applies most of the Goal Question Metric
(GQM) approach [BCR94, SB99] described in Section 2.9. Using this approach provides a structured and transparent evaluation. To simplify, this evaluation is less
formal than the GQM approach, i.e., the goal definition is less specific in its reference
to non-functional qualities such as usability, etc.
This section begins with Section 4.3.6.1, in which goals, questions, and metrics
are defined. Section 4.3.6.2 then presents the data collection, including the results
and hypotheses for the results. Next, the results are interpreted in Section 4.3.6.3.
Finally, Section 4.3.6.4 discusses possible threats to the validity of this evaluation.
4.3.6.1 Definition
As described in Section 2.9, the GQM definition model includes three parts: A goal,
a set of questions, and a set of metrics. The questions should answer whether the
goal has been reached and the metrics are used to answer the questions through
quantitative measurements. The definitions of goals and the questions, including
their metrics, follows.
Goal This evaluation should determine whether the previously found dependency
kinds are plausible, whether their names are well chosen, and how often they are
frequently in the behavior development. Additionally, this evaluation aims to determine whether the list is comprehensive ()contains sufficient kinds) or needs to be
extended. The final goal is an ordered list of dependency kinds containing the most
important kinds (Table 4.2). This must not necessarily be comprehensive.
Goal
Summary
Determine if the most important dependency kinds where covered
through the catalog. Get an ordered list of dependency kinds.
Table 4.2: Goal of the evaluation
In pursuit of these goals, the previously defined dependency kinds are used for the
survey. Furthermore, all component behaviors from the running example are used
for an analysis.
61
Questions and Metrics Through the survey and analysis of the running example,
the five questions shown in tables 4.3 and 4.4 shall be answered. These might not
be the only questions and metricshelpful to answering the goal and questions, but
these taken on as a reasonable set of evaluative angles to be pursued within scope
of a master’s thesis.
For each of the fourteen dependency kinds and their sub-kinds the following three
aspects should be considered:
• Plausibility : How likely is a dependency kind to be used in actual projects?
• Importance: How often is it required in relation to other identified kinds?
• Suitability of Name: How does it fit to the dependency kind’s description
and does it provide a immediate understanding of its purpose?
It is necessary to answer the questions of Table 4.3. These should be answered by
way of different metrics. Some require a formal analysis of the running example,
but most depend on a survey of domain experts.
Question Q1
Hypothesis H1
Metric
M1
Question Q2
Hypothesis H2
Metric
M2.1
M2.2
M2.3
M2.4
Question Q3
Hypothesis H3
Metric
M3.1
M3.2
Is the dependency kind plausible?
All dependency kinds should be plausible.
Average value of the given answers. Scala from 1 (implausible) to 5 (plausible).
How important is the dependency kind?
The importance varies greatly: some dependency kinds are
very important and others are relatively unimportant. The
ideal case would be that no dependency kinds of medium
importance are evaluated.
In how many other projects has this dependency occurred?
Scala from 1 (none) to 5 (many).
How often would it occur in a typical project? Scala from
1 (never) to 5 (in every RTSC of a discrete software component).
How often would it occur in one component RTSC with 4
ports? Scala from 1 (never) to 5 (very often).
Average number of dependency kind usages per component
in project of the running example.
Is the name for the dependency kind suitable?
80 percents of the names are accepted by the majority.
Average value of answers. 0 (No), 1 (Yes).
How many other distinct names were given?
Table 4.3: Questions for each dependency kind.
In addition to those questions which focus on the dependency kinds included in the
catalog, the evaluation further requires further information if important dependen-
62
cies are missing. The questions of Table 4.4 should determine the completeness of
the catalog and which kinds of dependencies might be missing.
Question Q4
Hypothesis H4
Metric
M4.1
M4.2
M4.3
Question Q5
Hypothesis H5
Metric
M5.1
M5.2
Is the catalog of dependency kinds complete?
The catalog is mostly complete. (at least 80%)
Average value of answers. 0 (No), 1 (Yes).
Number of components of the running example that contain
dependencies (shared elements) that are not matchable to
dependency kinds.
Cardinality of the set of all newly given dependency kinds of
the participants.
For what element types are dependency kinds missing?
In best case, no element types are missing.
List of unmatched elements’ types found in M4.2.
List of elements’ types mentioned in M4.3.
Table 4.4: Questions to evaluate the dependency kind list.
4.3.6.2 Data Collection
The data collection was done using two different methods. The results of metrics
M1, M2.1-M2.3, M3.1, M3.2, M4.1, M4.3, and M5.2 were collected using a survey of
ten MechatronicUML developers and users. The complete survey can be found
in Section C.1. Additionally, its detailed results are in Section C.2.
The other metrics are collected through manual analysis of the running example. In
this analysis, the thesis’ author examined all components’ behavior for the existence
of the dependency kinds and whether any shared elements cannot be matched.
Section 4.3.5 showed the analysis of the running example’s Normal Track Section.
The remaining Sections’ Real-Time Statecharts can be found at Appendix A in
Figures A.12 and A.18. In total, there were 29 dependencies of three different
dependency kinds detected in the three section kinds.
The hypothesis to each metric and the concrete result are shown below in Tables 4.5
and 4.6 (on page 64). For questions that focus on single dependency kinds, the
different results are annotated by “D” and dependency kind identifying number
used in Section 4.3.2. None of the hypotheses propose an ideal result, instead they
reflect the author’s expectation. The ideal case for each dependency is defined as
the hypothesis to each question. Using this personal expectation suggest whether a
developer’s expertise can compete with the evaluation results. The expectation of
plausibility is probably influenced by the complexity of the dependency kind, and
therefore not all dependencies have an expectation value of 5. The hypotheses of
M2.1 - M2.4 are the author’s personal assessments through experience with multiple
MechatronicUML projects.
63
M1
M2.1
M2.2
Kind
H
R
H
R
H
R
5 3.8 5 3.2 5 3.4
D1
4 4.1 3 2.5 3 2.6
D2**
5 4.3 4 1.7 3 2.7
D2a
5 3.8 2 1.2 3 2.3
D2b
5 3.8 3 1.6 3 2.6
D2c
5 3.1 2 1.5 3 2.3
D2d
4 4.0 2 2.3 2 2.8
D3
4 4.2 3 2.7 3 2.9
D4
4 3.7 2 1.7 2 2.2
D5
5 3.9 4 2.1 4 2.8
D6a
4 3.4 2 1.0 2 1.5
D6b
3 3.7 1 1.6 2 2.0
D7a
4 3.5 1 1.3 2 2.0
D7b
4 4.1 3 1.3 2 2.4
D8
5 3.5 4 2.3 3 2.6
D9
5 3.6 4 2.0 3 2.9
D10a
5 3.7 2 2.0 2 2.7
D10b
5 3.2 4 1.6 3 2.6
D11
5 3.5 2 1.3 2 1.9
D12
5 3.8 1 1.6 2 2.2
D13
5 3.5 2 1.6 3 2.0
D14
Avarage 4.6 3.7 2.7 1.8 2.7 2.4
M2.3
H
R
5.0
4.0
3.0
2.0
3.0
2.0
2.0
3.0
2.0
3.0
3.0
1.0
1.0
2.0
2.0
3.0
2.0
3.0
2.0
2.0
3.0
2.5
3.2
2.3
2.3
2.1
2.6
2.0
2.6
2.6
2.0
2.4
1.6
1.8
2.0
1.9
2.4
2.4
2.4
2.6
1.8
2.1
1.9
2.2
M2.4
H
R
3.0
2.1
1.0
0.1
1.0
0.0
0.0
1.0
0.2
1.0
0.0
0.0
0.0
0.5
1.0
1.0
0.2
0.8
0.3
0.1
0.4
0.7
H = Hypothesis
3.7
5.7*
0.0
0.0
5.7*
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.0*
6.0
0.0
6.0*
0.0
0.0
0.0
0.6
Importance†
R
R*
H
5.0
3.5
1.5
0.5
1.1
0.4
0.3
1.1
0.3
1.9
0.4
0.1
0.1
0.5
1.0
1.5
0.3
1.8
0.3
0.2
0.7
1.1
5.0
3.6
1.1
0.6
1.1
0.7
1.8
2.2
0.8
1.5
0.3
0.6
0.5
0.6
1.6
3.5
1.4
1.3
0.4
0.8
0.7
1.4
4.6
5.0
1.0
0.6
2.8
0.7
1.6
2.0
0.7
1.4
0.2
0.6
0.5
0.6
1.7
3.2
1.2
2.8
0.4
0.8
0.6
1.6
M3.1
H
R
0.3
0.5
1.0
1.0
0.8
0.9
1.0
0.7
0.6
1.0
0.9
1.0
0.9
0.6
0.8
0.8
0.8
1.0
0.8
0.7
1.0
0.8
0.4
0.5
1.0
0.7
0.8
0.9
0.9
0.8
1.0
0.9
1.0
1.0
1.0
0.8
1.0
1.0
0.9
0.9
1.0
0.9
0.9
0.9
M3.2
H
R
3
2
0
0
1
1
0
1-2
1-2
0
1
0
1
2
1
1
1
0
1
2
0
0.9
1
3
0
4
2
2
1
2
0
1
0
0
0
3
0
0
0
1
0
1
2
1.1
R = Result
† Importance Value := ((M2.1.R · M2.2.R · M2.3.R) + 3 · M2.4.R) / Maximum · 5
* D2, D2b, D9 or D11 could be used alternatively to D10a in 5.7 cases per Component.
The real values of D2 = D2b = D9 = 0 and D11 = 0.33 .
** It's importance value is the maximum of the formula and the sum of values of D2a-d
Table 4.5: Hypotheses and Results of Metrics 1 - 3.2 for each dependency kind
The Importance column of Table 4.5 has been calculated through the formula denoted by †. It weights the M2.4 through the factor 3 such that its values can become
almost as high as the multiplication of M2.1 - M2.3. It is normalized to the interval
of [0,5] by dividing by the column’s maximum value and multiplying by 5. The
hypotheses of M3.1 - M3.2 are personal expectations, too, which reflect the author’s
satisfaction level with the current dependency kind name, and that the author knows
alternative names in several cases, which might be more suitable.
Metric
M4.1
M4.2
M4.3
M5.1
M5.2
Hypothesis
0.5
1-2
0-2
non-urgent transitions
channels
Result
0.8
0
0
no unmatched elements
no new dependency kinds
Table 4.6: Hypotheses and Results of Metrics 4.1 - 5.2
64
The survey did not determine any new dependency kinds (see Table 4.6), i.e., no
participant suggested one. The interpretation and a detailed analysis of the result
and hypotheses are described in Section 4.3.6.3.
4.3.6.3 Interpretation
In this section the results of Tables 4.5 and 4.6 are compared with each other and
with their hypotheses. The thesis will answer each of the questions. This begins by
referring to the second column of Table 4.5.
Question 1 Most of the hypotheses in column M1 are close (differencing less
than 1.5 answer scale units) to the results. Each dependency kind was considered,
on average, between plausible (answer=5) and neutral (answer=3). Consequently,
it can be reasoned that each dependency kind is plausible (answer to Q1), which
supports hypothesis H1. However, the plausibility values of some dependency kinds
(D2d, D9, D11, D12, and D14) were overestimated, or the difference stems from
threats to validity (see Section 4.3.6.4).
Question 2 The column M2.1 shows that the dependency kinds differ strongly
in their values as was expected. Furthermore, kinds D2a, D7a, D7b, D8, D11,
D12, D13, and D14 are only known to a small number of participants from a few
projects, and kind D6b is entirely unknown. This makes D6b a candidate to be
dropped from the dependency language. The author’s prediction with respect to
the participants’ experiences of dependency kinds were generally overestimated and
also differ strongly at kinds D8, D11, D12, D13, and D14 with the result.
In column M2.2, differences between hypotheses and results are minimal. Only
three dependency kinds (D1, D6a, and D14) yielded a larger difference than 1.0
units. Again, the dependency kind expected to be used the least was D6b. One
other of which low use was expected, just under once per project (answer=2), is
D12. The discrepancy between the hypothesized and actual expected project’s use
for D6a probably arise from the author’s bias due to the experience with D6a in
projects. The forbidden state combination was used several times as an example
for a safety-critical requirement, such that the author overestimated its occurrence
by 1.2 units. Additionally, the use of shared clocks was slightly overestimated. It
appears as though the kind of clock dependency3 does not make much difference.
They are all rarely expected within a single project.
The column M2.3 mostly confirms the results of M2.2 in its contrasts to the
hypotheses.
In column M2.4, the running example is shown to use only three kinds of dependencies (D1, D10a, and D11). This may look like a miscalculation in relation to
the hypotheses, but could result from threats to validity (see Section 4.3.6.4), e.g.,
3
D4 is here not counted as a clock dependency.
65
the running example was too small and therefore not representative. Furthermore,
kinds D2, D2c, D9, and D11 could have, with very slight changes to the running
example’s inter-behaviors, replaced several D10a usages. Every component of the
running example also contains structures, which fit to a D6a. Nevertheless, through
additional elements such as assignments, the simple D6a could not be used. This
suggests that D1 is a more general dependency than D6a, which, in combination
with inner-behavior, enables the specification of D6a. Consequently, the D6a could
be interpreted as abbreviation for an inner-behavior and several D1’s.
To reason about the importance order, a simple formula is used which multiplies
the results of M2.1 - M2.3 and adds this to the result of M2.4 times 3 as offset.
The offset is chosen to increase the highest value of the analysis to almost the
same value as M2.1 · M2.2 · M2.3 (maximum = 25). To provide comparable values
for the hypotheses and the results, those values are normalized by dividing them
through their column’s maximum and multiplying this by 5. The thesis further
uses a maximum function for D2 (annotated with ** in Table 4.5), because D2ad are sub-kinds and D2’s value should not be less than the sum of all sub-kinds.
Because of the previously mentioned possibility that many of the running example
dependency could have been alternatively implemented using other kinds, Table 4.5
uses these potential values of M2.4 (indicated by *) to calculate R*. Using R*, the
thesis categorizes dependency kinds like the following:
• Very High: Every dependency kind with a value greater than or equal to 3.5:
D1, D2.
• High: Every dependency kind with a value between 2.5 and 3.4:
D2c, D10a, D11.
• Medium: Every dependency kind with a value between 1.5 and 2.4:
D3, D4, D9.
• Low: Every dependency kind with a value between 0.5 and 1.4:
D2a, D2b, D2d, D5, D6a, D7a, D8, D10b, D13, D14
• Very Low: Every dependency kind with a value less than 0.5:
D6b, D7b, D12
Thus, the hypothesis H2 was correct with the expectation that the importance
strongly differs, but there are only a few candidates which may be completely irrelevant. Furthermore, many dependency kinds fall into the middle categories, and so
the ideal case has not been reached.
Question 3 The results of M3.1 and M3.2 have reflected the suitability of most
names, including one that was not expected to be found suitable (D5). The results
yielded that hypothesis H3 is correct (80% of names are suitable). Only two of
twenty-one (1̃0%) dependency kinds’ names (D1, D2) were not accepted by majority.
The names found to be least suitable are those of kinds D1 (40%), D2 (50%), and
D2b (70%).
66
For D1, only one other name was, with slight variations, repeatedly (six times)
proposed. The participants proposed Synchronization as an improved label. This
was also one of the author’s alternatives. It better describes what occurs through
its application. Because acceptance for the new term was high (over 50%), Synchronization will be used from this point forward instead of Enforced Transition
Combination.
For D2, other names were proposed as predicted. The participants proposed Mutal
Exclusion (Mutex) three times and Change Event Condition once. These answers
and the additional question of the understandability of the description yielded that
the description of this dependency kinds was insufficiently understandable for the
surveyed. The author supposes that the purpose of this dependency kinds have
been misunderstood. The purpose is not to mutually exclude different paths. The
dependency kind would also be specifiable without a negative condition. It should
just give a general case to restrict (enable / disable) transitions by event occurrences.
Because the events are used to constrain transitions’ executions similarly to Clock
and Data Constraints, the thesis uses the simple term Event Constraint for D2 from
this point forward.
For D2b, the survey returned four proposals from three participants: Visit State
at Least Once Constraint, Initialization Constraint, Precondition, and Enabling
Condition. The last two are, in the author’s opinion, to vague; they do not include
the essential information about this kind involving states. Furthermore, neither
Enabling nor Precondition accurately express the focus. The first runs too long for
the author’s taste and does not fit into the other dependency kinds’ names. To use
the name Initialization State Constraint could be an alternative. However, because
the current term is accepted by the majority and because the thesis uses constraint
and condition synonymously, the current naming will remain as it is.
After reconsidering the dependency kind names, the author decided to further simplify the following names:
D10b from Conditional Data Push to Data Push,
D13 from Conditional Clock Remote Reset to Clock Reset.
The decision was motivated by several cases in which the words conditional and
remote led to confusion.
Question 4 This question cannot be fully answered here because the count of
answers to M4.1 is to low (only 5 participants) to reason about the result (80%).
However, there was no unmatchable element in the running example (M4.2) and no
new dependency kind described. Thus, the thesis assumes that the most important
dependency kinds must already be included in the list.
Question 5 In consequence to Q4 (M4.2 and M4.3 are empty), there are currently
no element types for which a dependency kind is missing. Again, this answer is very
uncertain, because it depends heavily on the validity of the previous results.
67
























y
D2
D1
D10a
D11
D2c
D4
D9
D3
D6a
D10b
D2a
Event Constraint
Synchronization
Data Pull
Data Constraint
Required Transition Constraint
Entry- / Exit-Clock Constraint
Data Merge
Message Sequence Constraint
Forbidden State Combination
Data Push
Required State Constraint
lowest
highest
Resulting Dependency Order Table 4.5 in descending importance order:
..
.




















y
D13
D5
D2d
D14
D2b
D8
D7a
D7b
D12
D6b
Clock Reset
Access-/ Leave-Counter Limitation
Once Required Transition Constraint
Clock Constraint
Once Required State Constraint
Bounded Active State
Forbidden Message Sequence
Allowed Message Sequence
Clock Merge
Allowed State Combination
At least D6b could be dropped in the dependency language after proving to be
unnecessary, because it can be specified indirectly by D6a. That is, the dependency
language does not lose expressiveness through its removal.
4.3.6.4 Threats to Validity
This evaluation focuses on the basic elements of Real-Time Statechart. It ignores
that Real-Time Statecharts allow multi-ports and can also specify concurrency between different hierarchical levels. This could affect the result when evaluating the
dependency kinds completeness.
It must also be noted that the survey results are based on a very small number of participants (max. 10 per survey question). This makes the data very dependent on the
participants’ experience, which varied considerably; some had only recently started
working with Real-Time Statechart, whereas others had years of experience. Given
these differences, it would be prudent to assign weights to the range of experience
levels. Nevertheless, all users have only worked with a few MechatronicUML
projects as only a few are exist in total. Consequently, even the experiences of those
surveyed are very limited and could be too project-specific.
Another issue is the scope and duration of the survey. It covers fourteen dependency
kinds and eight sub-kinds. In total, the survey includes 153 questions (7 repetitive
questions for each dependency kind). This took the participants around 1.5 - 2 hours
to complete, which may have been mental overload. Hence, the final question about
completeness might have been impossible to answer for those surveyed, as they may
have been either not yet able to differentiate among all dependency kinds. Similarly,
they may have been insufficiently familiar with dependencies to identify additional
kinds.
Furthermore, the choice to use the running example as input for the manual analysis
model was arbitrary. It is possible that this example is not especially representative
for mechatronic systems. It only contains three kinds of protocols and only three
components, which actually contain dependencies between among regions. These
68
components are all derivations of a track section and therefore quite similar in their
dependencies. Because only three kinds of dependencies were found at all, retrospectively, another MechatronicUML project would have been a more fitting choice.
Unfortunately, the author did not anticipate finding so few dependency kinds in the
running example.
Additionally, the metrics’ scales might be vague in that they may not have been
defined precisely enough for the participants surveyed, but also because the intervals
between 1 and 5 were not clear. Thus, different interpretations of the scale could
have lead to participants responding with different values even when they had the
same opinion.
The importance formula along with its thresholds could have been chosen differently. It should just provide a value which concatenates all metrics of Q2. Through
different weights and thresholds, the resulting importance ordering could be quite
different.
Finally, all goals, questions and metrics are solely the work of the author and do
not compare well to the ideal case, in which these would be generated by an ideally independent quality insurance team, which is recommended by GQM. Hence,
it is possible that the questions and metrics do not effectively achieve their goal.
Furthermore, their specification might imply the author’s hoped-for results.
4.3.7 Summary and Discussion of Step 3
In this step, many different dependency kinds were identified. These are classified as
either synchronous or asynchronous dependencies. They involve transitions, states,
state combinations, variables, and clocks from at least two regions. Furthermore,
most of them can be combined.
The application had shown that how such dependency kinds can be identified
strongly depends on the number of existing projects included in the model. In
the case of this thesis, there were very few projects upon which to draw. Furthermore, there was no existing collection of dependency kinds for extended hierarchical
real-time behavior, thus aggravating their identification and categorization forced
the author to rely on professional experience and to come up with informal requirements that describe possible dependencies. The evaluation was essential to ensure
that the developed catalog includes all important dependency kinds and excludes
dependency kinds which were unnecessary. Thereby, this step was the most timeconsuming one. However, in further applications this might be different. That is,
in other evaluations, more projects might contribute to the model, and the catalog
developed here could help to reduce the effort.
69
4.4 Step 4: Dependency Language Development
This section describes the dependency language developed over the course of this
thesis, including its syntactic and semantic elements. The fundamentals of this
sections are covered in Section 2.2 (DSL) and Section 2.3 (Textual Language).
In concretization of the requirements of Section 3.1.2, the language shall be:
1. capable of expressing all common dependency kinds identified in Section 4.3.
2. automatically processable, e.g, by the synthesis algorithm.
3. integrated with the development method MechatronicUML, allowing it to
reference elements of Real-Time Statechart, e.g., states and transitions.
4. intelligible for MechatronicUML stakeholders, i.e., also by customers who
do not necessarily have a computer science background.
5. sufficiently abstract to make it both useful and efficient for the main stakeholders.
The section continues with Section 4.4.1, which explains why a new language is
required. It continues with the addressed domain in Section 4.4.2 and stakeholders
in Section 4.4.3. In Section 4.4.4, the language’s syntactical elements are described
along with the dependencies from the catalog which can be expressed by them.
Section 4.4.6 describes how the language embeds into MechatronicUML. Finally,
Section 4.4.7 offers a summary and discussion of this step.
Not included in this thesis is an analysis of whether the language fulfills the requirements of and is accepted by its stakeholders. This remains for future work.
Furthermore, most technical details, e.g., meta-model, are left out to focus the description on the concrete syntax.
4.4.1 Discussion of Existing Languages
Considering the possible dependency languages, two kinds can be separated: messageaware and state-aware (see Section 4.3). State-aware languages allow references to
elements of state-based behaviors, e.g., transitions and states, while Message-aware
can only describe messages sequences. Hence, the state-aware languages are on a
much lower abstraction level. Both kinds can be extended by timing constraints and
data.
An example of a message-aware language including time and data is Modal Sequence Diagrams (MSD) [Gre10], which is a derivation of Message Sequences Charts
(MSC) [ITU99]. MSDs are already used for the requirement specification in MechatronicUML. However, modeling dependencies with a message sequence for statebased behaviors could become too sophisticated to be expressed them using state and
transition references. In particular, states commonly represent message sequences
and transitions represent incoming or outgoing messages, so message sequences can
in most cases be referenced through them. Such unnecessary complexity could
70
be seen at Event Composition Automaton (another message-aware language; see
Section 5.1). To express “A railcab must be registered at least 2.5s before it is allowed to join a convoy,” the equivalent event composition automaton, shown in Figure 5.1, already requires four transitions and three states. Another major problem
of message-aware language is that there are dependencies which cannot be expressed
by message sequences, e.g., merges, forbidden states, and dependencies that reference transitions which do not include messages. So, if the thesis had chosen to use
MSD, then it would have need to be extended for these dependencies. However, the
laborious specification of some dependencies and the fact that the inclusion of state
references is required to forbid state combinations, leads the message-aware languages to appear inappropriate when dependencies shall be modeled for state-based
behaviors like in MechatronicUML. Nevertheless, the abstraction on message
sequences might be better understandable and could been used to synthesize many
state-aware dependencies.
An example of a state-aware language is the State Composition Rule Language
(see Section 5.1). It allows states to be referenced, which makes it more compact
than the Event Composition Automaton, but with less expressiveness. The language only allows a very limited set of dependencies to be specified, as shown in
Table 4.1. It is the author’s option that this does not fit the thesis’ requirements
of a good understandable syntax (see Section 5.1), and is therefore unsuitable. Another example is TCTL [ACD93], which allows dependencies to be expressed, e.g.,
forbidden state combinations: AG(not(left.enterAllowed and right.enterAllowed)).
This property specifies that for every possible execution path, the state combination of both left.enterAllowed and right.enterAllowed (see Section 2.6.1) must not be
contained. However, it does not support the specification of data assignments and
neither transitions nor messages can be referenced. Additionally, the TCTL specifications are, in the author’s opinion, difficult to understand. Hence, TCTL likewise
does not meet the dependency language’s requirements. Furthermore, TCTL properties might be too imprecise, i.e., multiple semantically different refinements could
let a property become valid. In this case, an automatic synthesis algorithm using
TCTL would require additional input. Nevertheless, it would be useful to validate
the synthesis algorithm’s result. Thus, future work should analyze which dependency kinds are expressible and can be validated via TCTL. No other state-aware
dependency languages were found during the study of related work (see Chapter 5).
In summary, a new dependency language is required.
4.4.2 Domain
Mechatronic systems are domain of this language. Its particular subdomain it is the
software behavior development of discrete atomic components of MechatronicUML. In this domain, the models currently used to describe inter-behavior (behavior of a Real-Time Coordination Protocol role / a port-specific refinement) and
intra-behavior (behavior of a component) are Real-Time Statecharts. These are
state-based automata which can include time, data, hierarchy, and concurrency.
71
The language must therefore cover the dependencies which are expressible through
Real-Time Statechart (see Section 4.4). This requires that the language is stateaware and thereby allows all elements of the inter-behaviors to be referenced.
4.4.3 Stakeholder, Viewpoint and View
The primary stakeholders are the software behavior engineers who currently model
the component’s Real-Time Statechart. They will use the new language to specify
dependencies explicitly. They expect to be able to specify assignments, guards,
and invariants inside of dependencies, if possible, almost the same way they did in
Real-Time Statechart. However, the requirement engineers and even clients shall
be able to trace requirements, so the gap between informal dependencies should be
small. Here, a trade-off between usability and readability may exist. Furthermore,
safety engineers will also be able to read the dependency model in order to extract
a dependency graph from the model and use it for the failure analysis.
The language’s viewpoint is behavioral. Furthermore, there shall be one view to
model dependencies (XText Editor) which is embedded in the Component Diagram
Editor. However, it could be helpful for the dependency specification to use the
Real-Time Statechart Diagram Editor to view the inter-behaviors. Other views are
not planned.
4.4.4 Syntax and Semantics
In this section the language’s concrete syntax and its semantics are described. Furthermore, some dependency examples using the language are provided. More examples can be found in the catalog in Appendix B. The meta-model and its classes are
omitted here, but they can be found in Section D.1.1.
The concrete syntax of this language is fully textual. It uses expressive keywords to
declare the dependency kinds. The reason for this choice is given in Section 3.2.4.
The language’s static semantics are described informally. Its formal implementation
is not defined, due to time limitations. Furthermore, this section describes the
language’s dynamic semantics informally. A formal definition is provided by the
synthesis algorithm of Section 4.5. A first semantic requirement is: Each dependency
kind must reference at least two elements from different regions.
The section continues first with the basics of how elements of the Real-Time Statecharts can be referenced. Next, all possible conditions which can be used in several
dependency kinds are described. Then, the dependency kinds, their keywords, and
their possible combinations with different conditions are presented. Finally, this
section lists which dependency have been left out of the language and why.
The thesis uses a simplified grammar to illustrate the language, the implementation
of which can be found in Section D.1.2. The grammar uses a EBNF-like representation, which uses the following semantics: bold elements surrounded by ’ ’ are
72
terminals or keywords, brackets surround object and non-terminals, and parenthesis
describe the scope of cardinalities (*: 0..n; +:1..n; ?:0..1) and alternatives (|).
4.4.4.1 Referencing Real-Time Statecharts’ Elements
The following describes how States, Transitions, Variables, Clocks, Operations, Messages, and Events can be referenced.
Element4 Reference:=
([Name of Port] | ’inner’) ’.’
(([Name of Region] | [Name of State]) ’.’)* [Name of Element]
In MechatronicUML, there is no guarantee of globally unique names. However, it
ensures locally unique names. Thus, the specification must determine the local scope
to reference elements. The local scope can be specified through the element’s container. In particular, this requires only the names of containing states, statecharts,
and a behavioral element, i.e., a port / inner-behavior Real-Time Statechart. A
qualified name always begins with the port in which it is contained, or, if that it is
the inner-behavior, by the term inner. A dot indicates the end of the name5 . In case
that the element is directly contained by the port’s or inner-behavior’s Real-Time
Statechart, it continues with the element’s name. Otherwise, the containing regions’
names must be inserted in the middle, each followed by a dot. To the most left is
the top-level region, followed by the next highest, and so on. An example of a state’s
qualified reference in accordance with this production rule is shown below:
port1.State1.region1.SubState1
Name of Transition:=
[Name of Source] ’(’ [Priority]
’)-->’ [Name of Target]
A Transition does not have a name in MechatronicUML but the language derives
one from its structural features. An example of a transition reference:
port1.State1(1)-->State2
Event:=
[Transition Event] | [State Event] |
[State Combination Event] | [Message Event]
Besides those primitive Elements, there are several kinds of referenceable Events.
Each Event can be resolved to a Transition, or Entry- or Exit Event of MechatronicUML. Events can be used to specify Conditions, e.g, that a Transition is
required to fire, and to specify locations for data assignments, clock resets, etc. In
5
A name is not allowed to include dots or whitespaces.
73
the following, only Events which can be resolved to already existing transitions are
explained. Later, for Event Constrained Interval Conditions, several more Events
will be introduced which resolve to auxiliary transitions.
Transition Event:=
[Transition Reference]
The simplest event is the Transition Event, which contains a single reference to a
Transition.
State Event:=
(’entering’ | ’leaving’ [State Reference])
Through State Events, it is possible to reference Enter-State and Exit-State Events.
These can be used either for the specification of action for these events or to reference
all incoming resp. outgoing transitions, e.g., in a Synchronization. Which Event
kind is chosen is determined by the keyword entering or leaving and by a state
reference.
State Combination Event:=
(’entering’ | ’leaving’)
’combination of’ [State Reference] (’,’ [State Reference])+
Analogously to the State Event, there is a State Combination Event which can be
used to reference when the last missing state of the combination is entered as well
as when the combination is exited by means of an exit of any combination’s state.
In this way, it determines the event before or after the combination is active.
Message Event:=
(’sending’ | ’consuming’)
([Port Reference]’.’)? [Message Reference]
Another means by which to address a set of Transitions Events are Message Events.
These specify which Message must be consumed or sent, and, in so doing, declare a
set of Transitions which contain the specified message. The event can be declared
globally for all ports or for a single, specific port.
Synchronization Event:=
[Event] ’[’ [Expression] ’]’
The Synchronization Event extends the normal Event by a Selector Expression. This
is a special Event required only for the Synchronization with Selector. Hence, it is
not included in the Event production rule, which ensures that it can only be used
if it is explicitly included in Conditions or Dependencies production rules. More
details are provided in the Synchronization paragraph of Section 4.4.4.3.
74
4.4.4.2 Conditions
Conditions enable describing expressions that evaluate to true or false. As such,
these can be used to specify restrictions for transition executions and active states.
Additionally, they can be used to specify when a data assignment or a clock reset
should be done.
Conditions differ in their evaluation. Data, Clock, and State Status Conditions
are fixed in their evaluation, whereas the evaluation of Event Constrained Interval
Conditions is very flexible. An Event, like a signal which forces a decision about
the timing of its expiration, is volatile. For example, an Event Constrained Interval
Condition can specify that before an Event occurs the Condition evaluates to false
and afterwards always to true, i.e., it never expires. In the following, all Conditions
are described in detail.
Condition:=
[Composition Condition] | (’[’[Data Condition] | [Clock Condition] |
[Auxiliary Clock Condition] | [State Status Condition] |
[Hybrid Clock Condition] | [Event Constrained Interval Condition]’]’)
The Conditions can be subdivided to one composing and four normal types, which
are later divided further. Each normal Condition is surrounded by at least one pair
of brackets. This shall illustrate that the Conditions are used similarly to Guards
and Selector Expressions of MechatronicUML.
Composition Condition:=
’[’? [Condition] (’or’ | ’and’) [Condition] ’]’?
The Composition Condition is composed of two Conditions through logical operators. The composition kind is determined through a keyword. It can be either
or or and. Other operators are excluded to keep the language simple. However,
every normal Condition type contains its own inverse. Thus, more complex specifications like implications could be specified using an And Composition with the
inverse specification of the first Condition. For the same reason, an unary operator
for the inverse is not included. Its operator precedence binds and stronger than or).
To specify a different order, optional brackets can be used.
Data Condition:=
[Typed Name Element Reference] (’[’ [Array Position] ’]’)*
[Compare Operator] [Expression]
The Data Condition can be used to specify conditions for Variables and HybridPorts.
Its Expression can be simple values of the variable’s data type or every expression of
MechatronicUML’s Action Language. The only requirement is that the expression is comparable with the Typed Named Element, such that a boolean value can
be evaluated. This comparability should to be validated through static or dynamic
semantics.
75
Compare Operator:=
’==’ | ’<>’6 | ’<’ | ’<=’ | ’>’ | ’>=’
The Compare Operators allow the comparison of equality, unequality, and whether
the data type can be matched to numbers along with which value is smaller, smaller
or equal, greater, or greater or equal.
Clock Condition:=
’clock’ [Clock Reference] [Compare Operator] [Time Value]
The Clock Condition is similar to the Data Condition. To better distinguish between
them, the former begins with the keyword clock. It uses a Compare Operator and a
Time Value, which consists of an Expression and an Time Unit. The possible Time
Units are: nanosecond (ns), microsecond (µs), millisecond (ms), second (s), minute
(min), hour (h), and day (D). The Expression is inherited from the Action Language
and shall be of the Data Type Integer, such that the Clock Condition evaluates to
a boolean value.
Auxiliary Clock Condition:=
’last’ [Complex Event] [Compare Operator] [Time Value]
The Auxiliary Clock Condition is similar to the Clock Condition. It specifies a
time constraint, which depends on an auxiliary clock containing the time of the last
Complex Event occurrence. If the Event has not occurred before, then the clock
value contains the time since the Real-Time Statechart’s initialization.
State Status Condition:= 7
([State Reference] | (’combination of’ [State Reference]+))
(’active’ | ’inactive’)
The State Status Condition allows the defininition of a certain state or a combination
of states as being necessarily either active or inactive.
Hybrid Clock Condition:=
[State Status Condition] ’holds since’
[Compare Operator] [Time Value]
The Hybrid Clock Condition is an abbreviation for a State Status Condition and
an Auxiliary Clock Condition. It only evaluates to true if the specified status is
fulfilled, i.e., if the state is active, and its auxiliary clock expression is true. It could
be extended to every Condition type if required.
6
7
<> symbolize unequal
It uses State Event and State Combination Event without the keyword and so leaves kind
undefined.
76
Event Constrained Interval Condition:=
’between’ (’INIT’)? (’OR’)? [Complex Event]? ’,’
([Complex Event] | ’INFINITE’)
The Event Constrained Interval Conditions are required to specify conditions for
events. Since Events occur at a certain point in time and do not last, their occurrences must be saved to be determinable at any time. While the evaluation of
the previous Conditions was fixed, for an Event Constrained Interval Condition it
is flexible, i.e., the interval of its fulfillment can be freely chosen. The Condition is
fulfilled when the interval begins with the first Complex Event and ends with the
second Complex Event. Alternatively, the first Event could also be the Initialization
of the Real-Time Statechart. Even a combination of INIT and a Complex Event
is possible using the OR. In particular, the different intervals are illustrated in Figure 4.11. The keyword INFINITE can be used alternatively to a second Complex
Event. It specifies that the condition evaluates to true when the Complex Event
occurs for the first time and never changes back to false. INFINITE cannot be
combined with INIT, because this would specify a Condition that is always true.
Condtion: [between x, y]
INIT
x
y
x
y
x
t
Condtion: [between INIT, y]
INIT
x
t
Condtion: [between INIT OR x, y]
INIT
x
y
x
t
Condtion: [between x, INFINITE]
INIT
x, y: Event
x
x
x occurred
t
y
true
false
Figure 4.11: Event Constrained Interval Conditions’ Evaluation Examples
Complex Event:=
(’(’ ([Delayed Event] | [Counted Event] | [Composition Event]) ’)’)
| [Event]
The Complex Events consists of several (auxiliary) Events. So, it can be subdivided
into three auxiliary and one normal type. Auxiliary events can be nested freely and
are therefore surrounded by parentheses. Events (defined in the previous section)
make up the leaves of the Complex Event trees. Because auxiliary events depend
on an arbitrary number of ‘normal’ Events and additional conditions, they cannot
be resolved to existing transitions. The only exception builds the Or Composition
Event containing ‘normal’ Events.
77
Delayed Event:=
[Complex Event] ’delayed by’ [Time Value]
The Delayed Event contains another Complex Event. It delays the occurrence of its
sub event by a specified amount of time, i.e., a Time Value.
Counted Event:=
[Complex Event] ’counted’ [Integer] ’times’
The Counted Event occurs when the specified Complex Event occurs a specified
number of times.
Composition Event:=
[Complex Event] (’or’ | ’and’) [Complex Event]
Analogously to Composition Condition, the Composition Event allows to logical
composition of Complex Events. It is required to allow compositions of Events,
Delayed Events, and Counted Events. It occurs when one or both of its Complex
Events occurred depending on its logical operator. For Events there is no inverse,
therefore other logical compositions (beyond or and and) could not be specified.
4.4.4.3 Dependencies
The dependencies presented here model one or multiple dependency kinds of Section 4.3 Therefore, these use the previously defined Conditions and referencable
Elements and Event.
Dependency Model:=
[Comment]? [Dependency]*
The Dependency Model is the start production rule of the language. It consists of
arbitrary many dependencies and can additionally contain a comment.
Comment:=
(’/*’ -> ’*/’) | (’//’ !(’\n’|’\r’)* (’\r’? ’\n’)?)
A Comment can be specified either over multiple lines by opening with ‘/*’ and
closing ‘*/’ or, for a single line, by starting with ‘//’. This is how it is defined in
Java.
Dependency:=
([Forbidden State Combination] | [Synchronization]
| [Bounded Active State] | [Data Merge] | [Clock Merge]
| [Conditional Dependency]) ’;’ [Comment]?
78
Dependency is subdivided to six types. Each dependency ends with a semicolon
and can be optionally commented. The comment can document the dependencies’
relation to requirements. The separation of dependencies was based on the categorization of Section 4.3.3. However, this categorization is further extended here by a
new category called Conditional Dependency. This category groups the Constraint
Dependencies, Data Assignments, and Clock Resets.
In the following, details of the dependency are provided, including one example
for each dependency group. Further examples are given for every dependency kind
in Appendix B. In compliance with the requirements, two dependency kinds, and
one sub-kind were left out on purpose. The reasons for this decision are given in
Section 4.4.4.4.
Forbidden State Combination:=
’forbid’ [State Reference] (’,’ [State Reference])+
Forbidden State Combination requires at least two states. It is used for (6) State
Space Limitation dependency kind, especially to forbid state combinations. The
concrete syntax of (6) State Space Limitation from page 54 appears as follows:
forbid left.EnterAllowed , right.EnterAllowed ;
Synchronization:=
’sync’ ([Basic Event] | [Synchronization Event])+8 ’with’
([Event] | [Synchronization Event])+
(’using’ [Name])? ((’[’[Expression]’]’)? of type [Selector Type])?
Synchronization is used to synchronously couple Transitions as described in (1) Enforced Transition Combination. Therefore, it requires at least two Transitions, one
sending and one receiving; reference Transitions before the keyword with are sending
and those after with are receiving. The Events address either a single Transition or
a set, e.g, all incoming Transitions of a State. The channel which is used for the
Synchronization can optionally be named with the keyword using.
Additionally, Synchronization can use Selectors9 , which resemble the channel arrays
of Uppaal. These involve multiple channels which share a name and a selector Expression that determines which channel is addressed. This means that, Transitions,
that contain Synchronizations with Selectors, can dynamically change their channel.
To use a Synchronization with Selector requires that the channel contain a Selector
Type definition. The developer can specify these using the keywords of type. If a
Selector Type is specified, it requires either that only Synchronization Events are
specified or that the default selector Expression (between the name and type) is
specified. Synchronization Events can only be used in combination with a Selector
Type because they contain Selector expressions. Both can be validated through
8
When the grammar samples contain multipliers such as ‘+’ or ‘*’ without any separation symbol,
the elements are separated by ’,’, i.e., [Event]+ shall symbolize [Event] (’,’[Event])*.
9
Synchronizations with Selectors were not included in [BBB+ 12], but in v0.4 they will be.
79
static semantics.10 The concrete syntax of (1) Synchronization’s dependency from
page 53 takes the following form:
sync left.Idle()-->CheckRequest with followingSection.Idle()-->WaitingAnswer ;
Bounded Active State:=
’bound’ [State Reference]+
’by’ ’[’ [Clock Condition] ’]’
Bounded Active State enables the specification of (8) Bounded Active State. It consists of two parts: (1) A Reference of the states which shall be bounded and (2) the
bound which is specified as a Clock Condition. The current MechatronicUML
semantics do not allow Condition types here, so it might be required to catch wrong
Conditions via static semantics. The dependency of (8) Bounded Active State from
page 153 in concrete syntax uses a Clock Condition with a State Status Event and
takes the following form:
bound gate.GateClosing by
[ combination of ( gate.ClosingGate , detection.Pedestrians ) active < 5 s ] ;
Data Merge:=
’datamerge’ [Typed Named Element Reference]+ ’to’ [Name]
Data Merge models dependencies of kind (9) Data Merge . Therefore, it requires the
References of all elements that should be merged. If those elements have different
names, the first element’s name will be used as their new common name. Alternatively, the name can be specified using the keyword to. The dependency of (9) Data
Merge in concrete syntax appears as follows:
datamerge right.secFree , left.secFree ;
Clock Merge models dependency of kind (12) Clock Merge. In this way, it is analogous to Data Merge. The only differences are that it begins with the keyword
clockmerge instead of datamerge and that it references Clocks.
Conditional Dependency:=
(’if’ [Condition] | ’when’ [Complex Event])
’{’ ([Effect] ’;’)+ ’}’
Conditional Dependency describes a dependency of kind (2) Event Constraint, (4)
Entry-/ Exit-Clock Constraint, (5) Access-/ Leave-Counter Limitation, (11) Data
Constraint, (14) Clock Constraint, (10) Data Assignment, or (13) Clock Reset. That
is, it consists of a Condition and arbitrary many Effects. Alternatively, it can consist
10
Currently, to ensure a correct specification, the implementation does not allow a mix of Events
and Synchronization Events. This can be changed when the semantics are specified.
80
of a Complex Event and arbitrary many Effects. The condition specifies a time
interval for an Effect. The Complex Event specifies a point in time for an Effect. If
the Complex Event is used, it cannot be combined with an Enable Disable Effect,
because that requires an interval. How the Effects use the time interval or point
depends on their types.
Effect:=
[Data Assignment] | [Clock Reset] | [Enable Disable]
Effect is divided into three subtypes. Each Effect specifies a different kind of dependency. If not otherwise specified in the subtype, the Effect is applied every time
the Condition’s evaluation changes from false to true, and also when the Complex
Event occurs.
Data Assignment:=
’assign’ [Typed Named Element Reference]
([Unary Operator] | ([Assign Operator] [Expression]))
Data Assignment composes (10a) Data Pull and (10b) Data Push. It allows the
specification of an assignment for any existing variable and hybrid port. It can either assign an expression or be modified through an unary operator. Whether it
is a push or a pull depends on the variable to which a value is assigned and the
Event addressed by the conditiont. If both are from the same region, it is a pull,
and otherwise a push. Thus, it can be derived and must not be specially declared.
Unary Operator:=
’++’ | ’--’
Assign Operator:=
’:=’ | ’+=’ | ’=+’ | ’-=’ | ’=-’
Assignment operators are inherited from MechatronicUML’s Action Language.
The Unary Operators are used to increment and decrement, and the Assign Operator to assign arbitrary values. The dependency of (10a) Data Pull from page 155
in concrete syntax takes the following form:
when [ drive.Driving(1)-->Driving] {
assign drive.speedLimit := drive.min(160, 80 + 10 * master.convoyMembers) };
Clock Reset:=
’clockreset’ [Clock Reference]
Clock Reset models dependencies of kind (13) Clock Reset. It specifies which clock
should be reset and the Condition determines when this is done. The dependency
of (13) Clock Reset from page 159 in concrete syntax appears as follows:
when [ sensor.Idle(1)-->Idle] {clockreset door.open };
81
Enable Disable:=
(’enable’ | ’disable’) [Event]
Enable Disable is used for Constraint Dependencies. It uses the Condition to restrict
the execution of Events. It enables or disables the execution of the Event when the
Condition evaluates to true. An important semantic aspect is that when the Condition evaluates to false, this implies the inverse restriction for the Events. Without
this implication, the enable part would be useless: The enable cannot influence the
evaluation of an Event’s non-dependency constraints, it just expresses that the conditions have to be additionally fulfilled. Thus, when any condition is not fulfilled,
the Event must be disabled. Besides the restriction that this Effect is allowed only
in combination with conditions, an event that is disabled should not be used as
the second Complex Event of an Event Constrained Interval Condition, because the
same interval can be directly specified through the INFINITY keyword.
Depending on the Condition, the Conditional Dependency using Enable Disable can
state different dependency kinds. Combined with a Clock Condition, it becomes a
dependency of kind (4) Entry-/ Exit-Clock Constraint or (14) Clock Constraint.
By an Event Condition, it becomes any of kinds (2) Event Constraint, (4) Entry-/
Exit-Clock Constraint , (5) Access-/ Leave-Counter Limitation or a combination of
these. Lastly, in combination with a Data Condition it becomes a dependency of
kind (11) Data Constraint. The dependency of (2) Event Constraint from page 53
in concrete syntax takes the following form:
if [between right.Idle()-->CheckRequest, leaving right.CheckRequest] {
enable followingSection.Idle()-->WaitingAnswer ;
disable followingSection.Idle()-->IncomingRequest };
4.4.4.4 Unsupported Depedencies and Expressions
There are two dependency kinds not supported by the above described grammar:
(3) Message Sequence Constraint and 7) Message Sequence Limitation (see (7a)
Forbidden Message Sequence, (7b) Allowed Message Sequence). These two require
to express message sequences. Furthermore, they can require the specification of
timings for those message sequences. Such message sequences can be expressed by
MSD, which is especially designed for timed message sequences. Thus, this thesis
has not implemented its own syntax for sequence diagrams. This might also be
best because the current automatic synthesis examples suggested by the catalog for
those dependency kinds showed that these kinds are hardly synthesizable and result
in solutions with “bad-smell”. It is therefore recommendable to prevent use of these
dependency kinds and instead model the dependencies through other dependency
kinds like Event Constraints, Synchronizations and Forbidden State Combinations.
However, if such message sequence were to be embedded, it could be included as
another Event, thereby making (3) Message Sequence Constraint expressible by the
82
Constraint Dependency. (7) Message Sequence Limitation could then be implemented analogously to (6) State Space Limitation.
The dependency subkind (6b) Allowed State Combination was not implemented
because its importance proved to be very low. Specifically, the subkind is not necessary because (6a) Forbidden State Combination can make the same restrictions.
Its only nonredundant use is that its specification is smaller if the state space shall
be reduced by more than half. Nevertheless, integrating support of the white list
specification after a complete implementation of the automatic synthesis would not
require much additional work; The inverted subset of states space that uses the
black list implementation must be calculated.
4.4.5 Running Example: Dependency Model of Track
The new language makes possible the explicit modeling of all dependencies, of every
section kind, from the running example. For example, Section 4.3.5 identifies multiple assignments and synchronizations inside of Normal Track Section. Using the
new language, those dependencies can be expressed as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// NormalTrackSection
when [ ( left . RailCabApproaching (1) --> CheckRequest or
left . EnterDenied (1) --> EnterDenied ) ] {
assign left . free := inner . sectionFree };
when [ ( right . RailCabApproaching (1) --> CheckRequest or
right . EnterDenied (1) --> EnterDenied ) ] {
assign right . free := inner . sectionFree };
when [ entering precedingSwitch . Request ] {
assign precedingSwitch . free := inner . sectionFree };
sync left . CheckRequest (2) --> EnterAllowed ,
right . CheckRequest (2) --> EnterAllowed ,
left . EnterDenied (2) --> EnterAllowed ,
right . EnterDenied (2) --> EnterAllowed with
inner . Free (1) --> Occupied using acquire ;
sync left . WaitPostAction (1) --> Idle ,
right . WaitPostAction (1) --> Idle with
inner . Occupied (1) --> Free using release ;
4.4.6 Technical Integration into existing MUML Tooling
The MechatronicUML is based on EMF which was the reason for the dependency language developed here to be also based on EMF. It was developed with
XText [Ecl13], which is a Framework for building textual language based on EMF.
Another reason to choose XText was that parts of Real-Time Statechart are implemented by the Action Language, which uses XText too. The Action Language allows
the reuse of Expressions, TimeValues, and Operators, which is very convenient.
The integration into the MechatronicUML model was possible through MechatronicUML’s meta model’s extension mechanisms. This also made it easier to integrate the Dependency Language XText Editor, the integration of which is similar
to that of the Action Language XText Editor. It uses the Property Sheet Generator
(de.fujaba.properties .codegen), to embed into the Properties View. The Editor can
83
be opened from the Property View’s Extension tab, which is shown in Figure 4.12,
when an atomic component is selected in MechatronicUML’s Component Diagram Editor. Therefore, the SynthesizeableBehavior must only be double clicked.
Figure 4.12: Component Diagram Editor’s Property Extensions Tab
If such an extension does not exit, it can easily be created through the right-click
menu, shown in Figure 4.13 in the Fujaba sub menu, where there is a Create Synthesizeable Behavior option if an Atomic Component is selected.
Figure 4.13: Atomic Component’s Right-Click Menu.
When the Editor is open, the dependencies can be specified according to the previously described grammar. The developer is assisted in this through a code completion. For the specification of dependencies, it can be helpful having the Real-Time
Statechart diagrams opened in multiple tabs in the background, shown on another
monitor, or even printed on paper. Figure 4.14 shows the Editor in which the dependencies of the Normal Track Section are specified and in the background the
ports’ behavior. Some of the more technical details of the dependency language can
be found in Section D.1.3.
84
Figure 4.14: Dependency Language Editor surround by Real-Time Statecharts
This language includes all common dependency kinds except for (3) Message Sequence Constraint and (7) Message Sequence Limitation. It contains a textual
syntax using XText and integrates with MechatronicUML and the Action Language. It composes common parts of the different dependency kinds for a compact
grammar, e.g., the Conditions and Events. However, its formal semantic definition
is still incomplete.
The first step in language creation first requires a meta model. This could be
generated by XText after the definition of a grammar, however an independent meta
model is commonly cleaner, enables specification of multiple inheritances (even from
other meta models), and further provides the ability to switch to another syntax
more easily. Furthermore, a manually created meta model enables the specification
of OCL-Constraints for validation, derivation of values, and method specification.
The meta model specification is sophisticated, because it requires the identification
of different referenceable elements and commonalities of the dependency kinds at
hand. Thus, having a draft of the concrete syntax written down can be helpful when
defining the meta model, especially seeking out those the commonalities and situations in which another syntax might be better because of semantical differences.
During this step, the author could rely on the groups from the previous categorization for an first class structure. Nevertheless, multiple development iterations were
required to create the meta model, which is most likely common when developing a
new meta model. The most difficult decision was the question of where the separation should be made between Event, Conditions, and Dependencies. Furthermore,
85
the thesis concatenation of Data Assignment and Clock Reset with the Constraint
Dependencies might not be the final solution because they differ in their semantics.
Data Assignment and Clock Reset require a certain event at which they are applied
to while Constraint Dependencies require an interval. However, in order to allow for
a compact language with minimal Condition repetitions, the thesis has combined
these.
The XText implementation is straight forward once the developer has some expertise. It requires to know how to use the ScopeProvider, QualifiedNameProvider,
and ValueConverterService. The scopes of this language have been most general
meaning it allows more than the valid inputs. This enables a very quick prototyping. Through customizing the scopes, the content assistant’s proposals can be
reduced to correct inputs. Furthermore, exact scopes even validate manual inputs,
such that no incorrect specification can be done with precise defined XText Editor.
However, as previously describe another possibility to catch wrong inputs is to use
the validation mechanisms of an existing meta-model.
In this thesis, due to time limitations, both kinds of validations (static semantic)
were not specified. However, the implemented grammar varies a little from the
previous described grammar in order to limit wrong inputs, e.g., in Synchronizations
a mix of Events and Synchronization Event is currently not possible.
Using a XText Editor and an EMF model was very convenient during the evolution
of the meta-model and the grammar. Meta model changes had multiple times led
to corrupt test models. However, by storing the textual representation additionally,
it was very easy to restore the specification just by re-parsing it. Changes of the
grammar, were also directly checkable through the serialization. Hence, the thesis’
author can recommend to use the Frameworks.
If the chosen syntax is appropriate remains to be evaluated. However, the work’s
focus was that the grammar resembles programming languages, e.g., that conditional dependencies are specified with an if and that every dependency finishes
with an semicolon. This shall at least for the main stakeholders provide a familiar
impression.
86
4.5 Step 6: Synthesis Algorithm
This section describes in detail the automatic synthesis’ concept and its partial
implementation. It is based on a model transformation (see Section 2.4).
For MechatronicUML’s synthesis algorithm, the following requirements are derived from Section 3.1.3:
1.
2.
3.
4.
5.
The algorithm supports every syntax element of Real-Time Statechart.
It can handle any valid dependency model.
The algorithm is repeatable and requires no additional user input at runtime.
It preserves the distributed character and traceability.
It is incremental, such that later added dependencies can be integrated without
re-transforming other dependencies.
The section continues with Section 4.5.1, giving a more detailed description of the
activity (4.3.4) schematized by Figure 4.4 on page 47. Implementation details are
then presented in Section 4.5.2. Included therein is the description of which dependencies are already implemented and which are missing. Section 4.5.3 describes the
results of the synthesis algorithm for the running example as a simple case study.
Section 4.5.4 finishes with a summary followed by a discussion about the experience
gained during this step.
4.5.1 Synthesis Algorithm Process
The synthesis algorithm (Step 6 ) begins sequentially after Step 5 of Figure 4.1 on
page 39. It assumes that the inter-behaviors and inner-behavior have been verified
and the dependency model has been checked for most conflicts. Some conflicts’
detection might be impossible at earlier stage because there are conflicts depending
one synthesis algorithm chosen. For example, two synchronizations referencing the
same transition cannot been combined because the algorithm synthesized them as
two separate channels. Furthermore, there could be conflicts which are identified
more efficiently by the automatic synthesis. Thus, the synthesis algorithm needs
to catch these remaining conflicts. The algorithm divides the synthesis into the
following two sub-steps as shown in Figure 4.15:
• The first step creates an intra-behavior, which contains one Initial State.
Thereafter, each input, i.e., every Port’s Real-Time Statechart and the inner
Real-Time Statechart, is copied into a region of this Initial State. The result
is an intra-behavior with no dependency among its Initial State’s regions.
• In the second step, this intermediate intra-behavior is restricted using the dependencies specified in the dependency model. This integration is done by introducing synchronizations, shared data, and shared clocks. For more complex
dependencies, additional auxiliary elements can be introduced. The existing
states and transitions are only extended by additional actions, invariants, and
guards.
87
ComponentBehavior
[cf > 999]
registrar
noPlatoon
registered
clock: cf;
clock: ca;
rear
default
register /
noPlatoon
front
unregistered
[cf > 999]
noPlatoon
default
[cf > 999]
unregister
/
platoonProposal
/
default
platoonProposal /
/ breakPlatoon
clock: cf;
wait
requestUpdate /
cf ≤ 1000
entry / {reset: cf}
wait / performUpdate
cf ≤ 1000
entry
platoonProposal
/ / {reset: cf}
waiting
[cf <= 999]
ca ≤ 500
/ startPlatoon
entry / {reset: ca}
platoonProposal /
platoon
/ breakPlatoon
Sync!
[cf <= 999]
/ startPlatoon
platoon
wait
cf ≤ 1000
entry / {reset: cf}
platoonProposal /
clock: cf;
default
ca ≤ 2000
entry / {reset: ca}
platoonProposal /
[cf <= 500]
/ breakPlatoon
platoon
Copy Behavior
into parallel Regions
Integrate
Dependencies
Inter- & InnerBehaviors
/ startPlatoon
registered
clock: ce;
/ register
unregistered
Sync?
/ unregister
default
ce ≤ 2000
entry / {reset: ce}
/ requestUpdate
performUpdate /
waiting
ce ≤ 500
entry / {reset: ce}
Intra-Behavior
not((unregistered, true)
AND ((waiting; cr > 250)
OR (convoy; true)))
Dependency
Model
Legend
artefact
process step
Figure 4.15: Process of the Synthesis Algorithm
The result is an intra-behavior that contains concurrent regions and includes all
dependencies. If the intra-behavior still validly refines the port behaviors (see Section 2.6.3) must be checked.
The first synthesis step is required for the initial transformation and if an interbehavior or inner-behavior changes, whereas the second step must be applied initially and each time the input changes, e.g., every time a dependency shall be add
to the component’s behavior. Each of the steps should be implemented as incremental transformation, to prevent unnecessary re-transforming. This requires that
each dependency be applied independent of others, because otherwise new dependencies could cause those previously applied have to be reverted. Furthermore,
if they are not independent, complexer transformations are required which map a
combination of dependencies. Whether such an isolated synthesis is always possible
needs to be evaluated in future work. Besides, the transformation does not require
bi-directionality because it is not planned that manual adaptations of the result
should be transformed backwards. Manual adaptations are not stored in case of
a second synthesis, because this would contradict the forward engineering method.
Both steps shall provide traceability. Thus, a transformation that stores traces is
essential, otherwise tracing becomes very difficult. Furthermore, the intra-behavior
generated here shall preserve the structures of its origins. Through the preservation
of structure, the distributed character and human-readability are guaranteed. The
preservation can be established using parallel regions.
4.5.2 Implementation Details
The synthesis algorithm requires three inputs, but MechatronicUML model does
not have a containment for dependency models and inner-behaviors. Thus, the algorithm requires that the atomic components are extended by these two inputs. This
extension is done by the class SynthesizableBehavior which can be attached to the
atomic component by the ExtendableElement feature of MechatronicUML.
The user interface which creates and appends such SynthesizableBehavior object to
an atomic component is shown in Figure 4.13 on page 84. After the specification of
88
dependencies, the same menu can trigger the synthesis algorithm. For this reason,
the Fujaba sub menu contains the option “Synthesis Intra-Behavior” when an atomic
component is selected in the Component Diagram Editor. This selected atomic
component serves as input for the algorithm because it contains all references to all
three required inputs.
The synthesis algorithm is implemented as a QVT-O Transformation (see Section 2.4). QVT-O was chosen because it allows traces to be stored and is unidirectional, and because transformations for Real-Time Statechart written in QVT-O
already existed [Ger13]. These transformations include a library to copy MechatronicUML elements, which build a good base for the first step of the algorithm.
Furthermore, Gerking showed in his thesis [Ger13] that the resolve function of QVT
can be used to easily navigate from source elements to their mappings’ target elements. This is an important feature because the dependency model contains references to the source elements, but its restrictions need to act on the target elements.
The concrete implementation can be found in Section D.2.
The first algorithm step is implemented as follows. It copies every port’s RealTime Statechart and the inner-behavior’s Real-Time Statechart. The copy function
(see Section D.2.1) only copies contained elements of the Real-Time Statechart.
Referenced Objects which are not contained by the Real-Time Statechart are not
copied. Instead, their references are copied, such that the new Real-Time Statecharts
reference the same non-contained objects as the sources. This ensures that the copies
have the same semantics as the originals. The copies are afterwards embedded
in a new intra-behavior. This is done with another transformation. Its concrete
implementation is shown in Section D.2.3.
The second algorithm step transforms each dependency kind by different QVT-O
mappings. These mappings resolve referenced elements of the dependencies to the
newly create copies. Their syntheses’ modifications are implemented according to
the dependency catalog of Appendix B. The positions where actions, guards, and
invariants should be added are determined through the Events and Conditions. The
globalization of variables, operations, and clocks works according to an operation
which checks whether these are available from the current location. If they are
not available, they get globalized. Its concrete implementation is shown in Section D.2.4.
Currently, the synthesis can synthesize Synchronizations and Conditional Dependencies. The synthesizable Conditional Dependencies are limited to the following
Events: Transition, State, and Or-Composition Events. Alternatively, the following
Conditions can be used: Data Condition, Clock Condition, State Status Condition,
and Event Constrained Interval Condition (restricted by the Events from above). As
a result, the dependency kinds (1), (2), (10), (11), (13) and (14) (see Appendix B)
can be mostly synthesized. If the synthesis algorithm discovers dependencies that
could not yet be synthesized, then the algorithm informs the developer by issuing a warning about them. To create a readable serialization of this warning, the
algorithm uses XText’s serialization of the dependency language.
89
The synthesis does not yet support more dependencies due to time limitations.
Currently, there are already ideas regarding how the remaining dependencies could
be implemented. For example, to synthesize dependencies which depend on complex
Events like Delayed Events, the transformation could map them to auxiliary regions
which contain a behavior that observes whether the event occurred. However, their
synthesis’ implementation remains for future work.
Only one problem was experienced during the implementation, namely, that the
MechatronicUML only supports the association of one Real-Time Statechart to
a behavioral element (1-to-1 Reference). However, through the copy, two Real-Time
Statecharts exist for each port: one included in the intra-behavior and one refining
the role’s inter-behavior. Because the behavioral element reference is used to validate
the list of used messages,an error in either the original or the synthesized behavior
is generated. The synthesis algorithm shall not change its inputs and so does not set
the behavioral element for the copies. This insufficiency can only be fixed within the
MechatronicUML’s meta model. For example, multiple Behaviors could perhaps
posses the same Behavioral Element. Furthermore, an additional reference could
be introduced in DiscretePorts to store which Behavior is the current Protocol’s
refinement and another in AtomicComponents to reference their inner-behavior.
However, the changes must be postponed, because MechatronicUML’s current
meta model for version 0.4 is frozen.
4.5.3 Running Example: Synthesis of Sections
Applying the transformation to the running example’s sections resulted in the same
component’s behavior as with manual synthesis. This is a convincing demonstration
that the explicit dependencies can be synthesized. The complete input and output
can be found in Appendix A. The application shows that the automatic synthesis is
already useful even without having the support of every dependency kind. It requires
only seconds for the generation of intra-behavior. Additionally, even various orders
of dependencies lead to semantically equivalent behaviors; only some element change
according to the dependencies. Thus, the currently supported dependency syntheses
do not require a particular order. Furthermore, each dependency is applicable in
isolation, which is a result of the independent implementation. However, there is
still the chance that not all dependencies identified in Section 4.4, are independently
synthesizeable.
The partially implemented synthesis can already synthesize several dependency
kinds from the catalog in Appendix B, but there are still about half of the dependency kinds missing: (4) Entry-/ Exit-Clock Constraint, (5) Access-/ LeaveCounter Limitation, (6a) Forbidden State Combination, (8) Bounded Active State,
(9) Data Merge, (12) Clock Merge. This partial implementation, demonstrated that
90
the simple dependency kinds are implementable within several days when their meta
model structure was chosen nicely, e.g., this can be seen for Clock Reset and Data
Assignment.
QVT-O was chosen because of the already existing functions. It contained a library
for copying Real-Time Statecharts which only required slight changes. In general,
the implementation of such a copy library is not complex, but does consume time
and might be easier within other language. Alternatively, it might be a smart
choice to implement a generator which uses the meta model to create such a library.
Once the copy library was ready, the implementation of the synthesis algorithm was
convenient. Nevertheless, one drawback to using QVT-O is that transformations
currently cannot store and load their internal traces. Hence, enabling incremental
transformation, requires use of the external traces as explicit input, but the resolve
function of QVT-O cannot use them. This is inconvenient, because it forces a
separation between initial transformations and updates in the implementation. For
that reason, it is recommended that QVT-O be extended such that it is possible to
store the internal traces at the end of a transformation and to reload them when
it is triggered for an update again. In this way, the resolve operation would work
again, and only new elements would be mapped, because the map function would
use the old mappings for the already existing mappings.
For the completion of an incremental synthesis algorithm, it is required that the
remaining dependency kinds be possible to implement independently as well. From
the author’s experience, this is most likely possible. Once example is the merge of
variables or clocks is similar to an already implemented globalization, which only
globalizes variables that were not accessible. To introduce merges, the existing data
and clock dependencies require only that the variables be resolved once more in case
they have been merged before. Through the additional resolving, the dependencies’
syntheses stay independent. Another example is the forbidden state combination
which mainly resembles multiple synchronization dependencies.
In summary, if it is possible to modify QVT-O to reload its internal traces, or, if it is
decided that no incremental transformation is required, QVT-O is a sound choice for
the implementation of a synthesis. Otherwise, other techniques might be a better.
91
5 Related Work
This chapter includes reference to several neighboring research fields and works. It
provides a short overview of other work and an understanding of where this thesis
fits into a larger picture. Its sections are therefore ordered by importance, starting
with the work closest to that at the focus of this thesis.
Section 5.1 begins with the inspiration for this work, the behavioral synthesis of
Eckardt and Henkler, which defines a synthesis for MechatronicUML, respectively, for Timed Automaton. Next, Section 5.2 describes further syntheses which
are independent of MechatronicUML. All syntheses are analyzed for its dependency kind capabilities. Thereafter, Section 5.3 shows another application field that
could rely on dependencies. In Section 5.4, the application of another’s synthesis
approach is explained. Afterwards, Section 5.5 describes other development methods which contain similarities to MechatronicUML. The section analyzes how
these specify their component’s behavior and if a synthesis might be useful. Finally,
Section 5.6 distinguish the catalog, the term pattern, and some pattern catalogs.
The described challenge of building verifiable behavior models which depend on
multiple protocol roles (see Section 2.7) inspired Henkler [Hen12] to develop an
automatic approach to synthesis of real-time behavior. This approach specifies
how MechatronicUML’s inter-behavior can be synthesized. This makes his work
highly relevant to this thesis. It is in fact the foundation upon which the current
work is built.
The following explains the functionality of the synthesis algorithm, its dependency
language, and why it was insufficient for MechatronicUML. In fact, Henkler’s
approach for MechatronicUML is merely a translation of the original synthesis
approach of Eckardt and Henkler [Eck09, EH10]. Its insufficiencies were inherited by
the original approach. This description focuses on the original approach to elucidate
these issues.
The synthesis goal was the reduction of the error-prone and complex task of building verifiable component behavior (manually combining all its protocol roles) by
introducing a language, referred to as a set of composition rules that allows the
explicit description of formal dependencies between such roles. In their approach,
these composition rules and role behaviors serve as input to a synthesis algorithm
93
5. Related Work
which combines them in a centralized overall behavior. At this point, their output
needs only be verified through refinement checks.
Their process provides not only improved analyzability of dependencies through
an explicitly separated model, but also easier maintainability because the complex
overall behavior model may be set aside – in theory – by the developer. Nevertheless,
this depends on the completeness of composition rules.
In fact, Eckardt and Henkler’s approach [EH10] is built for Uppaal Timed Automata.
As described in Section 2.5, these contain data, clocks, and channels, however their
composition rules do not consider any kind of data transport. The result of this
language’s lack of expressiveness is that the overall behavior must still be manually
adapted.
The following takes a closer look at their composition language (Section 5.1.2), and
then at the synthesis process (Section 5.1.2). Afterwards, the differences between
their approach and that of this thesis are discussed.
5.1.1 Composition Rules
With composition rules, the behavior-engineer can specify dependency of roles using
states, clocks, and message references. With this in mind, Eckardt and Henkler
designed two new input languages to specify dependencies between timed automata:
State Composition Rules and Event Composition Automata.
1) State Composition Rule The state composition rules are specified as a stateaware language. They can restrict or even forbid certain state combinations. Such
a rule could look like the following rule r2 [Eck09, p.54].
r2 = ¬((unregistered; true) ∧ (convoy; cr > 50))
This rule prohibits the combination of the state unregistered with the state convoy
when the clock cr is greater than 50 time units. This means that the combination
is bounded. The combination could also be completely forbidden if cr > 50 was replaced by true. The overall syntax for a state composition rule ρ takes the following
form:
ϕ ::= x ∼ n | x − y ∼ n | ϕ ∧ ϕ | true;
ρ ::= ¬ργ
ργ ::= ργ ∧ ργ | ργ ∨ ργ | γ,
where x, y ∈ Clocks, ∼ ∈ {≥, >}, n ∈
94
N, ϕ ∈ Φ, γ ∈ States × Φ.
With state composition rules, it becomes possible to express the combination of multiple states through AND-Expressions or OR-Expressions in relation to upper-bound
clock constraints. It is worth noting that the grammar allows illegal expressions,
i.e., expressions that do not describe dependencies, because it does not specify that
the states of combination must be from different roles.
In comparison to the newly identified dependency kinds, this language only allows
specification of two kinds: The first is the State Space Limitation, because it can
express which state combinations are forbidden. The second is the Bounded Active
State, because it can express clock constraints for state combinations. However,
the second dependency kind is only partially expressible, since a bounded state
could be bounded by more than simple clock constraints. In the thesis’ dependency
description (see Appendix B) , there are numerous other constraint kinds which
could be used to bound the state. Furthermore, the bounded active state even
allows single states, and not just state combinations to be bounded.
2) Event Composition Automaton In contrast to state composition rules, the
event composition does not restrict the behavior in the context of states, but in
the context of messages or message sequences. For such input it is enough to be
message-aware.
In Eckardt and Henkler’s paper [EH10], they call these messages events and symbolize them by means of synchronization signals (see register! in Figure 5.1). Event
Composition Automata specify how the roles depend on the occurrence of certain (sequences of) messages, which can additionally be set in relation to clock constraints.
For example, a automaton can specify the requirement that a certain message be
consumed or sent at least a certain interval before another message can be consumed
or sent. All of this is expressed by a timed automaton that has different semantics
with respect to the Uppaal semantics. Its synchronization channels do not consume
or send a messages, but specify that the Event Composition Automaton must react
in parallel when these messages occur in any role. Hence, only messages which are
specified in roles can be used. The transitions and states of Event Composition Automata can be restricted by clock constraints. Figure 5.1 shows such an automaton,
which requires that the register message be sent at least 2500 time units before the
startConvoy message can be consumed. All messages not specified in an outgoing
transition of the Event Composition Automaton’s active state are unrestricted.
ec_initial
unregister!
unregister!
register!
ec_c1 := 0
ec_registered
ec_c1 >= 2500
startConvoy?
ec_registeredConvoy
Figure 5.1: Event Composition Automaton eca1 [Eck09, p.58]
95
5. Related Work
Although it is not described in Eckardt and Henkler’s work, this automaton makes
possible the forbidding of partial message sequences and even the enforcement of
certain sequences in relation to clock constraints. However, the greatest disadvantage of these rules are their complexity, which is often higher than if the restriction
had been introduced into the final model manually.
This language describes restrictions of message sequences and can even forbid them.
For this reason, it can express Message Sequence Limitations by blocking message
sequences explicitly through unfulfillable guards. Also timing dependencies of these
forbidden sequences can be described. Message Sequence Constraints are also possible to specify. As previously mentioned in Section 4.4.1, it is possible to express
other dependency kinds which refer to clocks, states, or transition if the referenced
elements are uniquely identifiable through clock values and message sequences. Even
so, despite it being possible for most cases, the expression of a dependency kind as
an event composition automaton would be considerably larger compared to the expression of the language defined in Section 4.4. Data dependencies and influence on
existing clocks ( 9) - 12) of Section 4.3) cannot be described.
5.1.2 Synthesis Process
The synthesis creates a “role-conform” (refining) centralized component behavior
model. The creation is defined in three phases:
1. The Inter-Behaviors (roles) are combined as a cartesian product. The result
is an exponentially larger centralized Uppaal timed automaton, including all
state combinations. This model now allows for all possible interleaving sequential executions of the roles.
2. The State Composition Rules are applied. This combines the additional invariants for time critical states and removes state combinations that are completely
forbidden.
3. The Event Composition Automata are applied. All automata are combined to
a parallel composition almost as in the first phase. However, in contrast to the
first phase, all event composition automata only “watch” messages and so their
transitions are merged as well, meaning that no new behavior is introduced
and a state change of an event composition automata always requires a real
transition to be used. The concrete algorithm can be found in [Eck09]. The
typical effect of phase three is a grows of states. This comes from the purpose
of the event composition automata. They commonly restrict certain message
sequences, which often do not match the timed automaton completely. In
consequence, some states must be divided to express the different sub-states
that are determined through the event composition automata.
96
5.1.3 Demarcation
In this section, Eckardt and Henkler’s work is compared with the goal of this thesis. It reveals that their approach not only differs in the model languages used,
but also in the synthesis algorithm. Their original work was defined for Uppaal
Timed Automaton without respect to data. Later, it was translated to Real-Time
Statechart [Hen12], but its expressiveness was not extended. Real-Time Statechart
syntax elements like data, hierarchy, and concurrency were not added. In the end,
only a limited subset of Real-Time Statechart was used as input for their translated
synthesis algorithm.
To enable the automatic synthesis of every dependency kind from Section 4.3, their
language and synthesis algorithm would require many adaptations. However, in
this thesis, the final goal is that the synthesis algorithm generates discrete software components’ Real-Time Statecharts that preserve the distributed character
of their ports’ Real-Time Statecharts. Furthermore, the intra-behavior shall be
maintainable, and traceable results and explicit dependencies shall increase analyzability. Hence, Eckardt and Henkler’s automatic synthesis is insufficient on multiple
counts:
• The old synthesis algorithm builds a cartesian product in its first phase which
not only blows up the complexity, but also prevents the model from being
easily traceable and executable in true parallel. Here, the thesis uses the
region concept of Real-Time Statechart such that not only the ports (roles)
are distinguishable, but also such that a later deployment to parallel processors
would be still possible and all states are easily traceable. This also conforms to
the semantic definition of Real-Time Statechart which assumes that messages
can only be processed at the port where they have been received and not
globally. Through the omission of the cartesian product, the old synthesis
algorithm for the composition rules is inapplicable for the thesis approach.
So, a new synthesis algorithm was conceptualized in the course of this thesis.
• Eckardt and Henkler’s dependency language (including both composition languages) is insufficient in its expressiveness. This requires the language to be
either extended or to replaced. For the following reasons, constructing a new
language might be better than adapting the old one. The event composition
rules are typically highly complex even for easily expressible dependencies like
a required state including timing constraints, which contradicts the goal of
better analyzability. Furthermore, Section 4.3 introduced many state-aware
dependency kinds, which can replace complex message sequences dependencies but therefore require a short syntax to be expressed. Besides, the state
composition rules allow to specification of constraints that are not dependencies. [Eck09, cf. p.56] Their syntax also contains superfluous options. It can
express the time bounded active state combination in two ways through its
language construction. For example, the previously mentioned rule r2 could
be substituted with:
r2 = ¬((unregistered; cr > 50) ∧ (convoy; true)).
97
5. Related Work
Since the state composition rules were not specified precisely in their syntax,
it has been decided to discard this part as well and write a completely new
language.
The newly developed language contains a tight syntax definition. It does not allow
to specification of elements other than dependencies, and it includes the previouslyunsupported dependency kinds. It also uses self-explanatory keywords instead of
pure mathematic notation, such that even unexperienced users should be able to
tell what the dependency describes.
The new synthesis concept uses several regions, making it possible to decode substates as they are needed for some message sequences in auxiliary regions but not
by splitting up existing states. This is core difference; the new synthesis tries to
preserve the state and transition structure of ports and does not introduce new
states in those regions. This is of great benefit to maintainability, traceability, and
ease of debugging.
In contrast to the approach of Eckardt and Henkler, this thesis does not include
a complete synthesis algorithm implementation due to time restrictions. Instead,
it provides a partial implementation to demonstrate how the synthesis algorithm
is planned. Nevertheless, the partial implementation can already be used with
MechatronicUML.
5.2 Other Component Behavior Syntheses
The synthesis algorithm of this work as well as Eckardt and Henkler’s requires that
port / interface behavior is described in state-based models. However, synthesis
approaches that use other behavioral descriptions to synthesize a component’s behavior also exist. The thesis discusses different types of such approaches below and
analyzes whether they can specify (other) dependencies.
5.2.1 Synthesis from partial behavior models
In contrast to this approach, many researchers create their initial component behavior using message sequence charts (MSC) [ITU99] or some derivation (like hMSC,
LSC, MSD) [KM94, UKM04, Loc07, Gre11]. One ancestor of these approaches is the
work of Biermann and Feldmann [BF72]. Their fundamental idea is that the most
important scenarios (behavioral use cases) can be expressed as message sequences.
These sequences describe existential requirements of the component behavior and
thereby specify partial behavior. They are used to create a state-based component
behavior which fulfills all message sequences, but generally is not the final behavior.
98
5.2 Other Component Behavior Syntheses
In their approaches, they commonly separate between inter- and intra-behavior.
Their inter-behavior between two components is specified as one or more MSCs.
The dependency specification describe message dependencies of different protocol
MSCs and can be done within multiple MSCs. The approaches often do not consider real-time, data transport, and the possibility of concurrency. As the summary
of dependency kinds and the demarcation from Eckardt and Henkler’s work showed
in Section 4.3.3 and Section 5.1.3, these missing elements lead to inexpressible dependency kinds. However, this lack of expressiveness is in some cases related to MSC.
Most were described for the expressiveness of the version from year 1993 [ITU93],
which has not cover most of these elements.
A typical problem of those approaches is that the specification of every possible
behavior through MSCs ends up being much larger than a state-based specification. Typically, the MSCs get blown up through branches, joins and loops, since
reoccurring behavior has to be specified in many MSCs. The hMSCs, from the version of year 2000 [ITU99], reduce this problem by specifying connections between
MSCs. That allows the specification of loops and joining of MSCs such that multiple
MSCs could share a single subsequent MSC. The joining of MSCs can be seen as a
state. Hence, the hMSC builds an hybrid approach of MSCs and state-based behavior description. As a result, the approaches become closer to state-based protocol
approaches. Still, many approaches are typically used to create a first version of
a behavior which is not fully specified and must later be manually refined due to
an insufficient synthesis or the lack of expressiveness of the used message sequence
language.
5.2.2 Synthesis from Properties
In addition to the approaches from above, there are approaches [LKMU08, VLMP04]
which synthesize state-based behavior models from properties like FLTL. They synthesize least specific behavioral models from properties such that they are fulfilled.
The properties allow restrictions on behavior in possible message sequences, and
therein strongly differ from scenarios which commonly1 describe message sequences
which must exist.
The resulting behaviors can contain two different types of transitions: those required for some property and those which are not forbidden but may not be needed.
These approaches also create an initial behavior model, which can then be further
restricted. Yet these approaches also fail to include features like concurrency.
1
Some approaches using negative fragments like in sequence diagrams of UML [UML11] could
exist.
99
5. Related Work
5.2.3 Synthesis from Scenarios and Properties
All previous approaches described in the previous two sections create a behavior
which contains required transitions (described in a scenario or derived from a property) and additional transitions for messages that could happen. Nevertheless, both
synthesis types do not specify a set of possible behavior by separating between those
types.
A hybrid approach [UBC07, UBC09] uses both the properties and scenarios to synthesis the behavior. In so doing, it distinguishes between required and “maybe”
transitions in a new behavioral model called Model Transition System (MTS). This
new model spans a set of Label Transition Systems (LTS) which conform to all properties and scenarios. It even allows the incremental introduction of new scenarios
or properties to further restrict the set until all maybe transitions were removed or
replaced by required transitions. When all maybe transitions are removed, the MTS
represents only a single LTS and so describes a fully specified behavior.
Despite that this approach connects both synthesis types and focuses on the specification completeness of the final behavior model. It still only uses LTS which is less
expressive in comparison with Real-Time Statecharts.
5.3 Model-based Behavioral Dependency Analysis
The behavioral dependency analysis (BDA) is a common part of the risk analysis.
It helps to plan redundancies and calculate fault tolerances. It extracts and often
visualizes dependencies between components, messages, and data. The model-based
BDA therefore uses the behavioral models specified in the MDSD process and so can
be carrier out much earlier than a code-based variant. [GBL06] is such a BDA which
allows analysis of dependencies specified by sequence diagrams (SD) and network
deployment diagrams. It investigates the number of messages between objects and
thereby can determine if they have dependencies. It also analyzes if the objects
contains transitive dependencies. The result of the analysis is a dependency graph
and several measurements describing the dependencies.
The BDA must often to reverse-engineer the dependencies, because the information
is not separate but included in the behavioral model. It must therefore know what
kinds of dependencies exist and how two recognize them. The dependencies are
an intermediate result, and, as above, sometimes merely counted and not expressed
using a specific language. Nevertheless, the reverse-engineering is very similar to one
of the problems this thesis focuses on, namely the identification of dependencies (see
Section 4.3) and explicit separation thereof into a specific model (see Section 4.4).
100
5.4 Synthesis of Component-based Systems
5.4 Synthesis of Component-based Systems
In component-based systems (CBS), where different existing components can be
assembled to create new functionality, the task of the connecting middleware can
also be expressed in a state-based manner. Synthesis approaches from this field
try to synthesize the executable code through a combination of traces like MSC
and state-based behavior like LTS. For example, Autili et al [AINT07] expect an
IDL for each component, including a usage protocol in MSC and LTS describing
the sequential message dependencies. They generate distributed wrappers for each
component, which implement the behavior. These synthesis approaches are not only
useful for classical CBS like DCOM and EJB, but also for the composition of web
services.
Unfortunately, web services often include a WSDL, but no behavioral protocol.
Bertolino et al. [BIPT09] attempt to fill this gap with an automated approach. Their
approach uses dependency analysis techniques and tests to distinguish a possible
behavioral protocol.
Again, these specifications all occupy a very abstract level (without time and concurrency), and so the synthesis cannot be directly compared with Real-Time Statechart,
but the general task of assembling several components that adhere to protocols is
the same.
5.5 Related MDSD approaches
In addition to MechatronicUML, many other languages and tools for the development of software systems exist. In this section, we describe some of those which
are close in their domain. Here, they are compared to MechatronicUML and distinguished whether they also require synthesis or why they can do without it. Furthermore, an overview is given of how they specify inter- and intra-dependencies.
5.5.1 SOFA 2
Software Appliances (SOFA) 2 [MHB13] is a software development method containing several similarities to MechatronicUML. It can specify components independently and compose hierarchical structures from them. Its components are
assembled by connectors over matching interfaces which rely on protocols. Furthermore, it allows dynamic reconfiguration of the component structures.
SOFA 2’s domain is component based software engineering (CBSE). It does not
include real-time behavior like MechatronicUML. Also, its protocols specify the
method invocation orders. The result is that, only sequential, alternative, and parallel orders can be specified; more precise time specifications are not possible. The
101
5. Related Work
protocols are used to specify a general behavior for multiple components. Each component’s interface can be considered a specific refinement. Whether the interface
specification conforms to the protocol can be checked [PV02]. The component’s
behavior definition is done separately through programming languages. For this
reason, SOFA 2 matches the assumption of the behavioral separation.
However, the intra-behavior in the SOFA 2 [MHB13] method is still considered
a black-box. Additionally, the specification of data and control flow are open issues [Mal12, cf. p.122]. The specification of dependencies between multiple interfaces is not included. Nevertheless, even at SOFA 2’s level of abstraction, a
dependency language and synthesis could be useful to prevent the implementation
from being inconsistent from its protocol.
A new dependency language for the SOFA 2’s approach could be similar to their
protocol definitions, because they would only need to specify (partial) method invocation orders between different interfaces. SOFA 2’s protocol syntax is similar
to regular expressions, but a protocol defines more or less the same as message sequence diagram. As previously described, such synthesis is already possible, but is
not as useful as in MechatronicUML because it only provides a starting point for
the component’s behavior development and definitely requires further specifications.
Through the too unspecific inter-behaviors, a synthesis method could only provide
method stubs for component behavior, including other method invocations, which
must be completed later.
5.5.2 Cadena
“Cadena [is] an integrated development environment for high-assurance CCM-based
systems.” [HDD+ 03, p.1] It is developed for CORBA Component Model to test the
effectiveness of automated analyses like model checking, fault tolerence analysis, and
dependency analysis. Its motivation is “that support for reasoning about correctness
properties of component-based designs is essential” [HDD+ 03, p.1] to form an effective basement for developing real-time safety/mission-critical systems. Its major
contribution is its automated extraction of checkable transition systems from CCMs
and a lightweight dependency analysis. Therefore, Cadena extends the CCM IDL
with lightweight dependencies, component modes, and state-transition semantics.
Cadena also includes a component assembly framework. The component assembly
and extended IDL allow the creation of inter-component communications checkable
for global properties. Additionally, they also allow inter-behavior, intra-behavior
messages, and data dependencies to be traced. Cadena can also generate code stubs
and calculate deployments.
Cadena’s property specification (CPS) specifies existing statuses. For those statuses,
dependencies among trigger-port-actions (receptacle / data sinks) and responseport-actions (obstacle / data source) can be defined. Furthermore, the CPS includes
textual state-based behavior descriptions. These lead to a redundant specification
102
5.5 Related MDSD approaches
of the dependencies, because the state-based automatically includes them. This has
the benefit that the dependencies can be used as properties for the model checker.
In comparison to MechatronicUML, Cadena is a tool including small extensions
to the existing language CCM. It only includes an untimed behavioral description
with no concurrency inside its intra-behaviors. This kind of behavior specification
further makes the impression that it quickly grows unreadable due to its fully textual
nature. In addition, the inter-behavior communication is only specified by component IDLs and not by port protocols such that a compositional verification is not
possible. Therefore, Cadena could have problems with developing bigger systems.
In contrast to the thesis approach, in which the dependency of different ports must
be separately described and used to synthesis the behavior, Cadena requires to
manual specification of the dependency as well as its behavior. This is possible of
course, but the validation of a component’s behavior gets more complex in Cadena
than with the MechatronicUML methodology.
CPS can only express data and message dependencies. These specify which input
triggers what output based on internal states. CPS does not consider time in the
behavior of a component, because Cadena assumes that time is a non-functional
requirement and that a component’s output message rate is determined through
its input message rates and dependencies. Additionally, CPS uses global states for
all ports of one component. This can become problematic when there are several
ports which all require at least two states, because their combination to global
states is exponential. In conclusion, Cadena does not cover the full range of thesis’
dependency kinds. Its state addressing does not fit with orthogonal states and
therefore cannot rely on a synthesis, because it does not specify behavior for single
ports.
5.5.3 COMDES-II
The Comdes-ii framework [KSA07] offers a generative approach for designing distributed, real-time embedded control systems. Its main objective is to improve the
reliability of control systems. Therefore, it contains model-checking and code generation. Its structural architecture, shown in Figure 5.2, consists of distributed actors
which communicate via asynchronous messages. Each actor can have input and
output ports, through which actors can be assembled. For these ports, each actor
contains one driver that converts the incoming or outgoing signals. For concrete
computations or control algorithms, each actor contains also one control task that is
connected to the driver signals. In this control task, different function blocks (FB)
can be assembled, of which there are four different kinds. The basic FB contains inputs, parameters, internal variables, and a table which maps them to output signals.
So, the basic FB allows continuous data flow to be processed. The computation of
control signals happens in state machine FBs combined with modal FBs. A state
machine FB consists of a flat state machine in which state changes depend on the
incoming control signal and its transitions. As an output, it only provides the current
103
5. Related Work
communication
signal
actor
environment
msg_3
i_m
i_d
data_1
msg_1
msg_2
o_m
o_m
i_m
i_m
Actor_1
output communication
driver
control task
out
inp
im1_v
out
om1_v
i_msg_1
inp
inp
o_msg_1
out
out
id1_v
inp
data_2
Actor_2
input communication
driver
inp
o_m
o_d
om2_v
Task
out
inp
i_data_1
out
o_msg_2
Actor_1
local signal
input physical driver
input
input1
function block instance
inp
inp
inp
con
control
inp
output
output1
out
pre_processing_1
input2
active state and whether the last input
has lead to state change. The real output calculation is extracted into modal
FBs, which receive the state machines
output and additional inputs and determines similar to a basic FB the output values. The last kind, the Composition FBs, can create a hierarchical structure of basic, modal, state machine, and
composition FBs.
out
Real-time constraints and concurrency
are defined with respect to actors.
Comdes-ii separates the timing behavior from its functionally as does Cadena.
It assumes that the actors work in readdo-write operational semantics and expects that the computation takes zero
logical execution time. Its only realtime properties for the execution of the
actor are deadlines. Through these, the
approach shifts the timing analysis to a
schedulability analysis.
output2
pre_processing_2
Task
MechatronicUML strongly differs
from Comdes-ii because it integrates
Figure 5.2: Hierarchical
architecture time. This integration allows timing
model of a Comdes-ii sys- constraints and deadlines in the compotem [KSA07, p.3]
nent behavior (Real-Time Statechart).
Because of its flat un-timed state machines, Comdes-ii is unable to express
concurrency and timing dependency in
intra-behavior. Furthermore, data and
message dependencies are only implicitly specified inside the FBs. Comdes-ii does
not specify any protocols and further includes no compositional verification such
that the model-checking becomes problematic for bigger systems. Due to the fact
that neither separate dependency description nor port behavior exists, synthesis is
impossible and so exclude from Comdes-ii. In any case, the Comdes-ii approach
does not include any fault tolerance analysis, which makes their stated objective of
focusing on reliable control systems creation unlikely to succeed or shows that the
approach is insufficient.
104
5.6 Software Patterns
5.6 Software Patterns
The catalog of dependency kinds (see Appendix B) developed over the course of
this thesis provides solutions for reoccurring problems which can be used arbitrarily
often. This conforms to the pattern definition of Gamma et al. [GHJV95, cf. p.2f.].
However, according to Buschmann et al.’s definition [BMR+ 96, cf. p.10], it is only a
pattern if the described solution is a good or even the best choice. The dependency
kind catalog provides a list of possible solutions for one language which were already
evaluated in Section 4.3, however it was not evaluated thoroughly if better solutions
exist. Because of that, and due to a general tendency of the term’s over-extensive
usage, the thesis has not employed the term “pattern”. The thesis’ author prefers
to think of the catalog as an abstraction of the dependencies’ implementation.
During the analysis of related work, no catalog was found which specifies “patterns”
in a way fully comparable with the thesis’s dependencies, due to their different domains and points of focus. However, some catalogs intersect slightly with the one
used by this thesis. For example, the paper Workflow Patterns of van der Aalst
et al. [AHKB03] includes patterns like Exclusive Choice and Synchronization which
are similar to dependencies like Forbidden State Combination and Synchronization,
respectively. The Real-time Specification Patterns of Konrad and Cheng [KC05] is
another example of a catalog that intersects. It includes the Bounded Invariant Pattern, which is similar to Bounded Active States. There is also the Response Pattern
and the Bounded Response Pattern, which are similar to the Event Constraints and
the Entry- / Exit-Clock Constraints, respectively.
105
6 Conclusion
This chapter briefly summarizes the thesis’ contents in Section 6.1. Section 6.2
then goes on to describe the benefits of the new method and its implementation.
The thesis closes in Section 6.3 with an outlook on open issues and possible future
work.
6.1 Summary
Software development for mechatronic systems requires handling extended hierarchical real-time behavior. Using a compositional software development method, the
behavior is split for manageability and verifiability reasons into inter-behavior and
intra-behavior. This enables independent component development. However, the
component in question must guarantee all protocols, a nontrivial task.
There are other researchers like Eckardt and Henkler [EH10], who have addressed
this challenge (see Chapter 5). Yet non of their approaches display the high expressiveness possessed by Real-Time Statecharts, i.e., hierarchy, data, time, and concurrency. This thesis provides an approach which tackles this problem. It describes
how a component’s extended hierarchical real-time behavior (intra-behavior) can be
synthesized from formal dependencies and inter-behavior protocols. Furthermore, it
provides a method to integrate such automatic synthesis with development methods. The method is divided into several steps which were described in Chapter 3.
Chapter 4 then showed how these steps can be applied to MechatronicUML. During this application, Section 4.1 first analyzed the MechatronicUML’s process,
followed by Section 4.2, which adapted the process according to the requirements
of Chapter 3. An automatic synthesis was already planned for MechatronicUML, but its process and the automatic synthesis proved to be inappropriate for
the expression and synthesis of every dependency kind of such complex behavior
as Real-Time Statechart. Next, different kinds of dependencies between extended
hierarchical real-time behavior (Real-Time Statechart) were identified and evaluated in Section 4.3. This step ensures that the newly developed automatic synthesis
does not unintentionally disregard any dependency kind. The result of this step
is that there are many dependencies which were unsupported by MechatronicUML [BBB+ 12] and Henkler’s synthesis [Hen12]. The thesis continued with the
design of a new textual syntax to specify dependencies between ports’ Real-Time
Statechart and inner-behavior in Section 4.4. The dependency language abstracts
from the implementation in Real-Time Statechart, e.g., no globalizations, channel
107
6. Conclusion
creations must be specified. Furthermore, it allows the abstraction from auxiliary
variables and clocks towards their essential meaning, e.g., that a certain state must
be active. Lastly, the thesis partially designed a synthesis algorithm using QVT-O
in Section 4.5. This algorithm uses the new dependency language to synthesize a
component’s behavior.
6.2 Benefits
The thesis’s first benefits is that the dependencies are now specified in an explicit
model. It provides a single point from which to maintain them, which is very useful
when it comes to multiple development iterations. Additionally, it can compress
the dependencies down to their essential meaning and use compact specifications to
spare the engineer from implementation details. Furthermore, the complex components’ behavior specification (e.g., Real-Time Statecharts) requires be less frequent
manual adaptation. The explicit dependency specification also leads to better model
quality, because every supported dependency is now always implemented in the same
way. This repeatability further shortens the intra-behavior development iterations.
Besides the usage as input for the synthesis algorithm, the explicit dependency can
be also helpful for other analysis purposes. An example for other usages is described
among the benefits of MechatronicUML (see final paragraph).
Every development method could profit of these benefits, when it separates interbehavior from intra-behavior. The automatic synthesis method should not only
be applicable to MechatronicUML but also to methods like SOFA 2 [MHB13].
Their integration is guided by the general automatic synthesis process described
in Chapter 3. This guidance should be of great benefit, because the process defines required artifacts, process steps, and embedded analysis steps for the synthesis
of verified intra-behavior. Furthermore, the integration can rely on the MechatronicUML example and profit from the dependency kind catalog of Appendix B
developed in the course of this thesis. Furthermore, the application provides an
example dependency language which can be used as a basis for future development
methods’ languages.
MechatronicUML developers obviously profits the most from this work, because
the synthesis method is already partially implemented. It is usable to partially
automatically synthesize currently developed examples like the running example.
Furthermore, the new dependency language improves considerably the explicit specification of dependencies with respect to Henkler’s composition languages [Hen12].
Besides, through the language’s mostly complete expressiveness, it becomes useful
for analyses like safety and behavior dependency analysis. For example, the safety
analysis of the systems behavior requires knowledge of which influences components
exert on each other. This is connected with the dependencies between ports, because they define possible directions for the propagation of failures. Currently, such
propagations are extractable from Timed Automata [PHS13] but it might also be
possible to rely on dependencies instead, because they can be mapped similarly
108
6.3 Future Work
to the illustration in Figure 1.3 on page 3. Besides these benefits, the running
example showed that the new dependency language improved the specification of
multiple similar components, because the textual representation then often required
few changes and could mostly be copied from one component to another.
6.3 Future Work
In the future, the general synthesis method needs further evaluation, e.g., through
the application on SOFA 2 [MHB13]. Additionally, the application to MechatronicUML should be completed. This requires that the dependency languages
definition is finished, which in turn requires the restriction of scopes to legal inputs
and the implementation of semantics like the requirement that a dependency must
reference two regions. Additionally, full application requires that a conflict analysis
be carried out and conflict detection implemented, which would provides enough
information to resolve the conflicts. Next, the automatic synthesis algorithm must
be completed and, optionally, optimized. To complete the application, all remaining
evaluation steps, e.g., the acceptance test, must be carried out. It must be shown
whether the automatic synthesis is possible for every kind of dependency and if it
preserves the refinements.
The synthesis method should also be evaluated for its scalability, i.e., for its applicability to projects with greater complexity. Furthermore, whether the entire automatic synthesis approach provides measurable improvements, could be evaluated
using a comparative study which takes into account the time required to model a
project with the dependency model and the same implementation, done manually.
During the language’s development, the author noticed that it might be useful to
extend the events, perhaps using assignment and operation events which resolve to
the transitions at which the assignment / operation happens. Also, the hybrid clock
condition could be extended such that it allows every condition kind to be contained
rather than only state status conditions, because it is possible to implement a clock
for any condition and, furthermore, to check if the condition still holds.
The language development also showed that the dependency kind catalog could be
restructured and some dependency kinds merged. This being the case, the catalog
demands further evaluation. Here, an empirical analysis of dependency used in
multiple projects would be helpful, but there are currently not enough projects to
do so.
The multi-ports and reconfiguration of MechatronicUML were omitted from this
thesis. A continued dependency kind analysis should cover the former. Additionally,
the analysis could more thoroughly study the expressiveness of this dependency
language, MSD [Gre10], TCTL [ACD93], and other property languages with respect
to the dependency kinds, because this thesis only described dependencies examples
which were not covered and does not describe precisely which kinds are specifiable.
109
6. Conclusion
Additionally, a graphical representation of dependencies could be introduced in the
Component Diagram Editor, which shows the dependencies’ directions and kinds.
This would be similar to a safety analysis, and the explicit dependency model might
as a result be interesting for safety analysis, e.g., for MechatronicUML to generate Timed Failure Propagation Graphs instead of using Timed Automata [PHS13].
The similarity might additionally be useful for reverse-engineering explicit dependencies from final component behaviors.
110
Bibliography
[ACD93]
Rajeev Alur, Costas Courcoubetis, and David Dill. Model-checking in
dense real-time. Information and computation, 104(1):2–34, 1993. 16,
71, 109
[AHKB03] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P.
Barros. Workflow patterns. Distributed and Parallel Databases, 14(1):5–
51, 2003. 105
[AINT07] Marco Autili, Paola Inverardi, Alfredo Navarra, and Massimo Tivoli.
Synthesis: A tool for automatically assembling correct and distributed
component-based systems. In Proceedings of the 29th international conference on Software Engineering, ICSE ’07, pages 784–787, Washington,
DC, USA, 2007. IEEE Computer Society. 101
[Bar02]
Geoff Barnbrook. Defining Language: A local grammar of definition
sentences, volume 11. John Benjamins Publishing Company, 2002. 12
[BBB+ 12] Steffen Becker, Christian Brenner, Christopher Brink, Stefan Dziwok,
Christian Heinzemann, Renate Löffler, Uwe Pohlmann, Wilhelm Schäfer,
Julian Suck, and Oliver Sudmann. The mechatronicuml design method –
process, syntax, and semantics. Technical Report tr-ri-12-326, Software
Engineering Group, Heinz Nixdorf Institute, University of Paderborn,
August 2012. Vers. 0.3. xi, 3, 4, 20, 22, 40, 41, 47, 79, 107
[BCR94]
Victor R. Basili, Gianluigi Caldiera, and Dieter H. Rombach. Encyclopedia of Software Engineering, volume I, chapter The Goal Question
Metrics Approach, pages 528–532. John Wiley & Sons, 1st edition edition, February 1994. 26, 27, 61
[BF72]
Alan W. Biermann and Jerome A. Feldman. On the synthesis of finitestate machines from samples of their behavior. Computers, IEEE Transactions on, C-21(6):592–597, 1972. 98
[BHSH13] Christian Brenner, Christian Heinzemann, Wilhelm Schäfer, and Stefan Henkler. Automata-based refinement checking for real-time systems. In Proceedings of Software Engineering 2013 – Fachtagung des
GI-Fachbereichs Softwaretechnik, volume P-213 of Lecture Notes in Informatics (LNI). Gesellschaft für Informatik e.V., March 2013. 3, 17
111
Bibliography
[BIPT09] Antonia Bertolino, Paola Inverardi, Patrizio Pelliccione, and Massimo
Tivoli. Automatic synthesis of behavior protocols for composable webservices. In Proceedings of the the 7th joint meeting of the European
software engineering conference and the ACM SIGSOFT symposium on
The foundations of software engineering, ESEC/FSE ’09, pages 141–150,
New York, NY, USA, 2009. ACM. 101
[BK08]
Christel Baier and Joost-Pieter Katoen. Principles of model checking.
MIT Press, 2008. 2
[BKPS07] Manfred Broy, Ingolf H. Krüger, Alexander Pretschner, and Christian
Salzmann. Engineering automotive software. Proceedings of the IEEE,
95(2):356 –373, feb. 2007. 1
[BLL+ 96] Johan Bengtsson, Kim Guldstrand Larsen, Fredrik Larsson, Paul Pettersson, and Wang Yi. Uppaal. In Rajeev Alur, Thomas A. Henzinger,
and Eduardo D. Sontag, editors, Verification and Control, volume 3 of
Lecture Notes in Computer Science, pages 232–243. Springer, 10 1996.
14, 17, 22
[BMR+ 96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stal. Pattern-Oriented Software Architecture, Volume 1: A
System of Patterns. Wiley, Chichester, UK, 1996. 105
[Bol04]
W. Bolton. Mechatronics: Electronic Control Systems in Mechanical and
Electrical Engineering (3rd Edition). Prentice Hall, 2004. 1
[BR69]
Nato science conference report. In J.N. Buxton and B. Randell, editors,
Software Engineering Techniques, Rome, Italy, October 1969. NATO
Science Committee. 15
[BY04]
Johan Bengtsson and Wang Yi. Timed automata: Semantics, algorithms
and tools. In Jörg Desel, Wolfgang Reisig, and Grzegorz Rozenberg,
editors, Lectures on Concurrency and Petri Nets, volume 3098 of Lecture
Notes in Computer Science, pages 87–124. Springer, 2004. 3, 14, 42
[CGP00]
Edmund M. Clarke, Orna Grumberg, and Doron A. Peled. Model Checking. MIT Press, 2000. 16
[CH03]
Krzysztof Czarnecki and Simon Helsen. Classification of model transformation approaches. In Proceedings of the 2nd OOPSLA Workshop on
Generative Techniques in the Context of the Model Driven Architecture,
2003. 13
[CH06]
Krzysztof Czarnecki and Simon Helsen. Feature-based survey of model
transformation approaches. IBM Systems Journal – Model-driven software development, 45(3):621–645, July 2006. 13, 14
[Cha09]
Robert N. Charette. This car runs on code. IEEE Spectrum, February, 2009. http://spectrum.ieee.org/green-tech/advanced-cars/
this-car-runs-on-code/0. 2
112
Bibliography
[CK02]
María Victoria Cengarle and Alexander Knapp. Towards ocl/rt. In
Lars-Henrik Eriksson and PeterAlexander Lindsay, editors, FME 2002:
Formal Methods—Getting IT Right, volume 2391 of Lecture Notes in
Computer Science, pages 390–409. Springer Berlin Heidelberg, 2002. 16
[CKNZ12] Edmund M. Clarke, William Klieber, Milos Novacek, and Paolo Zuliani. Model checking and the state explosion problem. In B. Meyer and
M. Nordio, editors, Tools for Practical Software Verification, Lecture
Notes in Computer Science. Springer-Verlag, 2012. To appear. 3
[Cla08]
Edmund M. Clarke. The birth of model checking. In Orna Grumberg and
Helmut Veith, editors, 25 Years of Model Checking, volume 5000 of Lecture Notes in Computer Science, pages 1–26. Springer Berlin Heidelberg,
2008. 16
[CSN08]
Kai Chen, Janos Sztipanovits, and Sandeep Neema. Compositional specification of behavioral semantics. In Rudy Lauwereins and Jan Madsen, editors, Design, Automation, and Test in Europe, pages 253–265.
Springer Netherlands, 2008. 13
[DBHT12] Stefan Dziwok, Kathrin Bröker, Christian Heinzemann, and Matthias
Tichy. A catalog of real-time coordination patterns for advanced mechatronic systems. Technical Report tr-ri-12-319, Software Engineering
Group, Heinz Nixdorf Institute, University of Paderborn, February 2012.
25
[Dvo08]
Radomil Dvorak. Model transformation with operational qvt. Long
Talk - EclipseCon, 2008. http://help.eclipse.org/juno/topic/org.
eclipse.m2m.qvt.oml.doc/references/M2M-QVTO.pdf. 14
[Eck09]
Tobias Eckardt. Synthesis of reconfiguration charts. Master’s thesis,
University of Paderborn, 2009. xi, 8, 93, 94, 95, 96, 97
[Ecl13]
Eclipse Foundation. Xtext 2.4 documentation, April 2013. 13, 36, 83
[EH10]
Tobias Eckardt and Stefan Henkler. Component behavior synthesis for
critical systems. In Holger Giese, editor, Proceedings of the First International Symposium on Architecting Critical Systems, ISARCS 2010,
Prague, Czech Republic, June 23-25, 2010, volume 6150 of Lecture Notes
in Computer Science (LNCS), pages 52–71. Springer-Verlag Berlin Heidelberg, June 2010. 4, 8, 29, 30, 42, 44, 46, 93, 94, 95, 107
[Eme90]
E. Allen Emerson. Temporal and modal logic. Handbook of Theoretical Computer Science, Volume B: Formal Models and Sematics (B),
995:1072, 1990. 16
[GBK+ 03] Holger Giese, Sven Burmester, Florian Klein, Daniela Schilling, and
Matthias Tichy. Multi-agent system design for safety-critical selfoptimizing mechatronic systems with uml. In OOPSLA 2003 - Second
International Workshop on Agent-Oriented Methodologies, 2003. 26
113
Bibliography
[GBL06]
Vahid Garousi, Lionel C. Briand, and Yvan Labiche. Analysis and visualization of behavioral dependencies among distributed objects based on
uml models. In Oscar Nierstrasz, Jon Whittle, David Harel, and Gianna
Reggio, editors, Model Driven Engineering Languages and Systems, volume 4199 of Lecture Notes in Computer Science, pages 365–379. Springer
Berlin Heidelberg, 2006. 100
[Ger13]
Christopher Gerking. Transparent uppaal-based verifcation of mechatronicuml models. Master’s thesis, University of Paderborn, May 2013.
25, 26, 48, 89
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-oriented Software. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 1995. 105
[Gie03]
Holger Giese.
A formal calculus for the compositional patternbased design of correct real-time systems. Technical Report tr-ri-03240, Lehrstuhl für Softwaretechnik, Universität Paderborn, Paderborn,
Deutschland, July 2003. 3, 18, 19, 20, 25, 29, 40
[Gre10]
Joel Greenyer. Synthesizing modal sequence diagram specifications with
uppaal-tiga. Technical Report tr-ri-10-310, University of Paderborn,
February 2010. 70, 109
[Gre11]
Joel Greenyer. Scenario-based Design of Mechatronic Systems. PhD
thesis, University of Paderborn, October 2011. 98
[GS12]
Holger Giese and Wilhelm Schäfer. Model-driven development of safe
self-optimizing mechatronic systems with mechatronicuml. Technical Report tr-ri-12-322, Software Engineering Group, Heinz Nixdorf Institute,
University of Paderborn, April 2012. 3
[GV06]
Holger Giese and Alexander Vilbig. Seperation of non-orthogonal concerns in software architecture and design. Software and System Modeling
(SoSyM), 5(2):136 – 169, June 2006. 2
[GW09]
Holger Giese and Robert Wagner. From model transformation to incremental bidirectional model synchronization. Software and Systems
Modeling, 8:21–43, 2009. 14
[HBDS14] Christian Heinzemann, Christian Brenner, Stefan Dziwok, and Wilhelm
Schäfer. Automata-based refinement checking for real-time systems.
Computer Science - Research and Development, 2014. submitted - not
yet published. xi, 1, 119
[HDD+ 03] John Hatcliff, Xinghua Deng, Matthew B. Dwyer, Georg Jung, and
Venkatesh P. Ranganath. Cadena: an integrated development, analysis,
and verification environment for component-based systems. In Software
Engineering, 2003. Proceedings. 25th International Conference on, pages
160–172, 2003. 102
114
Bibliography
[Hen12]
Stefan Henkler. Ein komponentenbasierter, modellgetriebener Softwareentwicklungsansatz für vernetzte, mechatronische Systeme. PhD thesis,
University of Paderborn, June 2012. 4, 8, 29, 30, 39, 40, 42, 43, 93, 97,
107, 108
[HG03]
Martin Hirsch and Holger Giese. Towards the incremental model checking of complex realtime uml models. In Holger Giese and Albert Zündorf,
editors, Proc. of the first International Fujaba Days 2003, Kassel, Germany, volume tr-ri-04-247 of Technical Report, pages 9–12. University of
Paderborn, 10 2003. 19
[HH11]
Christian Heinzemann and Stefan Henkler. Reusing dynamic communication protocols in self-adaptive embedded component architectures. In
Proceedings of the 14th International Symposium on Component Based
Software Engineering, CBSE ’11, pages 109–118. ACM, June 2011. 17
[Hil99]
Rich Hilliard. Views and viewpoints in software systems architecture.
In Position paper for the First Working IFIP Conference on Software
Architectur, San Antonio, TX, February 1999. 12
[IEE09]
Ieee standard for information technology-systems design- software design
descriptions. IEEE STD 1016-2009, pages c1–40, 2009. 9
[ISO94]
ISO. Open Systems Interconnection Basic Reference Model: The Basic
Model. International Organization for Standardization, 1994. ISO/IEC
7498-1:1994. 1
[ITU93]
ITU. Recommendation Z.120: Message Sequence Chart (MSC). Geneva,
1993. 99
[ITU99]
ITU. Recommendation Z.120: Message Sequence Chart (MSC). Haugen
(ed.), Geneva, 1999. 70, 98, 99
[JAB+ 06] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, Ivan Kurtev, and
Patrick Valduriez. Atl: A qvt-like transformation language. In Companion to the 21st ACM SIGPLAN Symposium on Object-oriented Programming Systems, Languages, and Applications, OOPSLA ’06, pages
719–720, New York, NY, USA, 2006. ACM. 14
[KC05]
Sascha Konrad and Betty H. C. Cheng. Real-time specification patterns.
In Gruia-Catalin Roman, William G. Griswold, and Bashar Nuseibeh,
editors, Proceedings of the 27th International Conference on Software
Engineering (ICSE 2005), St. Louis, Missouri, USA, May 15-21, 2005,
pages 372–381. ACM, May 2005. 35, 105
[KM94]
Kai Koskimies and Erkki Mäkinen. Automatic synthesis of state
machines from trace diagrams. Software: Practice and Experience,
24(7):643–658, 1994. 5, 98
115
Bibliography
[KSA07]
Xu Ke, Krzysztof Sierszecki, and Christo Angelov. Comdes-ii: A
component-based framework for generative development of distributed
real-time control systems. In Embedded and Real-Time Computing Systems and Applications, 2007. RTCSA 2007. 13th IEEE International
Conference on, pages 199–208, 2007. xi, 103, 104
[KW07]
Ekkart Kindler and Robert Wagner. Triple graph grammars: Concepts,
extensions, implementations, and application scenarios. Technical Report tr-ri-07-284, Software Engineering Group, Department of Computer
Science, University of Paderborn, June 2007. 14
[Leh12]
Sebastian Lehrig. Assessing the quality of model-to-model transformations based on scenarios. Master’s thesis, University of Paderborn, Heinz
Nixdorf Institute, 2012. 14
[LKMU08] Emmanuel Letier, Jeff Kramer, Jeff Magee, and Sebastian Uchitel. Deriving event-based transition systems from goal-oriented requirements
models. Automated Software Engineering, 15(2):175–206, June 2008. 99
[Loc07]
Malte Lochau. On Synthesizing Statecharts from Live Sequence Chart
Specifications. Diploma thesis, TU Braunschweig, Institute for Programming and Reactive Systems, February 2007. 98
[Mal12]
Michal Malohlava.
Variability of Execution Environments for
Component-based Systems. PhD thesis, Charles University of Prague
- Department of Distributed and Dependable Systems, Prague, Czech
Republic, September 2012. advisor: Tomas Bures. 4, 102
[MC81]
Jayadev Misra and Kanianthra Mani Chandy. Proofs of Networks of
Processes. IEEE Transactions on Software Engineering, 7(4):417–426,
1981. 18
[MCG05]
Tom Mens, Krzysztof Czarnecki, and Pieter van Gorp. A taxonomy
of model transformations. In Jean Bézivin and Reiko Heckel, editors,
Language Engineering for Model-Driven Software Development, number
04101 in Dagstuhl Seminar Proceedings, 2005. 13
[MHB13]
Michal Malohlava, Petr Hnetynka, and Tomás Bures. Sofa 2 component framework and its ecosystem. Electr. Notes Theor. Comput. Sci.,
295:101–106, 2013. 4, 101, 102, 108, 109
[MOF11]
OMG - Object Management Group. Meta Object Facility (MOF) Core
Specification 2.4.1, August 2011. formal/2011-08-07. 11
[NBP]
Neue bahntechnik paderborn. http://www-nbp.uni-paderborn.de. 1
[OCL12]
OMG - Object Management Group. Object Constraint Language (OCL)
2.3.1, January 2012. Document formal/2012-01-01. 11, 14
116
Bibliography
[PHS13]
Claudia Priesterjahn, Christian Heinzemann, and Wilhelm Schäfer.
From timed automata to timed failure propagation graphs. In Proceedings of the Fourth IEEE Workshop on Self-Organizing Real-time Systems
(SORT 2013). IEEE, June 2013. accepted. 108, 110
[Pnu77]
Amir Pnueli. The temporal logic of programs. In Foundations of Computer Science, 1977., 18th Annual Symposium on, pages 46–57, 1977.
16
[PV02]
Frantisek Plasil and Stanislav Visnovsky. Behavior protocols for software
components. IEEE Transactions on Software Engineering, 28(11):1056–
1076, 2002. 102
[QVT11]
OMG - Object Management Group. Meta Object Facility (MOF)
2.0 Query/View/Transformation Specification 1.1, January 2011.
formal/2011-01-01. 14
[SB99]
Rini van Solingen and Egon Berghout. The Goal/Question/Metric
Method: a practical guide for quality improvement of software development. THE McGRAW-HILL COMPANIES, 1999. 26, 27, 61
[Spi89]
John Michael Spivey. The Z Notation: A Reference Manual. PrenticeHall, Inc., Upper Saddle River, NJ, USA, 1989. 16
[Sta73]
Herbert Stachowiak. Allgemeine Modelltheorie. Springer, Wien, December 1973. 9
[SVB+ 06] Thomas Stahl, Markus Völter, Jorn Bettin, Arno Haase, and Simon
Helsen. Model-driven software development - technology, engineering,
management. Pitman, 2006. 9, 10, 11
[THHO08] Matthias Tichy, Stefan Henkler, Jörg Holtmann, and Simon Oberthür.
Component story diagrams: A transformation language for component
structures in mechatronic systems. In Matthias Gehrke, Holger Giese,
and Joachim Stroop, editors, Proceedings of the 4th Workshop on Objectoriented Modeling of Embedded Real-Time Systems (OMER 4), Paderborn, Germany, volume 236 of HNI-Verlagsschriftenreihe, Paderborn,
pages 27–38. Heinz Nixdorf Institut, 2008. 14
[UBC07]
Sebastian Uchitel, Greg Brunet, and Marsha Chechik. Behaviour model
synthesis from properties and scenarios. In Proceedings of the 29th international conference on Software Engineering, ICSE ’07, pages 34–43,
Washington, DC, USA, 2007. IEEE Computer Society. 5, 100
[UBC09]
Sebastian Uchitel, Greg Brunet, and Marsha Chechik. Synthesis of partial behavior models from properties and scenarios. Software Engineering, IEEE Transactions on, 35(3):384–406, 2009. 100
117
Bibliography
[UKM04]
Sebastian Uchitel, Jeff Kramer, and Jeff Magee. Incremental elaboration
of scenario-based specifications and behavior models using implied scenarios. ACM Trans. Softw. Eng. Methodol., 13(1):37–85, January 2004.
98
[UML11]
OMG - Object Management Group. Unified Modeling Language (UML)
2.4.1, August 2011. Document formal/2011-08-05. 3, 20, 22, 99
[VBD+ 13] Markus Völter, Sebastian Benz, Christian Dietrich, Birgit Engelmann, Mats Helander, Lennart C. L. Kats, Eelco Visser, and Guido
Wachsmuth. DSL Engineering - Designing, Implementing and Using
Domain-Specific Languages. dslbook.org, 2013. 10, 11, 12
[Vis01]
Eelco Visser. A survey of strategies in program transformation systems.
Electronic Notes in Theoretical Computer Science, 57:109–143, 2001. 13
[VLMP04] Hung Tran Van, Axel van Lamsweerde, Philippe Massonet, and
Christophe Ponsard. Goal-oriented requirements animation. In Requirements Engineering Conference, 2004. Proceedings. 12th IEEE International, pages 218–228, 2004. 99
[Wir77]
118
Niklaus Wirth. What can we do about the unnecessary diversity of
notation for syntactic definitions? Commun. ACM, 20(11):822–823,
November 1977. 12
Appendix A
Running Example
On the next pages, the complete running example models are shown, beginning with
the structural definition and thereafter with the behavior definition.
A.1 Structure Definition
This section shows the structural definition of the running example. Starting in
Figure A.1 with the repetition of the scenario illustration, which shows two RailCabs
and three different Section Types.
Normal Track
Section (ts1)
Switch (ts3)
Railroad
Crossing (ts4)
RailCab 1
RailCab 2
Normal Track
Section (ts2)
φ: at most one
RailCab on a section
ψ: following section is free
Figure A.1: Railcab Scenario [HBDS14, cf.]
119
A. Running Example
This scenario requires the following five atomic components and one structured
component type shown in Figure A.2.
sec1
left
followingSection1
sec2
right
left
right
RailCab
Normal
TrackSection
Switch
precedingSection
precedingSection
followingSection2
bottom
RailRoadCrossing
status
left
action
precedingSection
left
right
right
precedingSection
:CrossingSW
left
gateStatus
Gate
status
permanentClose
right
gateAction
CrossingSW
action
gateStatus
:Gate
gateAction
permanentClose
permanentClose
Figure A.2: Component Types of the Running Example
A Component Instance Configuration can specify the scenario within MechatronicUML as illustrated in Figure A.3.
left
right
ts1:Normal
TrackSection
right
left
sec1
r1:RailCab
sec2
bottom
ts3:Switch
following
Section1
ts4:RailRoad
Crossing
preceding
Section
right
ts2:Normal
TrackSection
r2:RailCab
sec1
sec2
Figure A.3: Component Instance Configuration conform to Scenario
120
A.2 Behavior Definition
This section begins with the protocol definition and thereafter continues with the
definition of each component’s behavior. For each component, first all refinements
of protocol behavior (ports’ behaviors) are described, followed by a model of the
inner-behavior. Thereafter, the dependency model specifies what dependencies exist
between these refinements. Finally, the application of the automatic synthesis is
shown, wherein the changes caused by the dependencies are highlighted. The results
do not distinguish from the previously manual component behaviors.
A.2.1 Protocol
In the example, their are two protocols. The first protocol is the Next Section protocol shown in Figure A.4, which is used for the Section to Section communication.
It is required to determine if the following Section is free. The second protocol is
the Enter Section protocol. Its roles are presented in Figure A.5. It is for the communication between Section and Railcab, which is required such that Railcabs can
request permission to enter the Section.
section
{reset: c1}
Idle
clock c1
Request
Inv: c1<= 500ms
{free := int<0,1>}
[c1 >= 400ms] /
sectionStatus(free)
switch
/ requestSectionStatus()
{reset: c2}
Idle
variable boolean status
clock c2
WaitForSection
Inv: c2<= 550ms
[c2 >= 550ms] sectionStatus /
{status := sectionStatus.free}
Figure A.4: Next Section Protocol’s Roles
121
A. Running Example
clock c1
railcab
Idle
newSection /
request()
{reset: c1}
enterAllowed /
{reset: c1}
confirmExit /
enterDenied / Waiting
WaitForAnswer
c1 ≤ 2s
enterAllowed /
{reset: c1}
Approved
c1 ≤ 2min
/ enterSection()
{reset: c1}
EnterSection
c1 ≤ 100ms
confirmEntry /
LeaveSection
c1 ≤ 100ms
/ leaveSection()
{reset: c1}
DriveOnSection
clock c2
section
Idle
RailCabApproaching
c2 ≤ 100ms
{free := int<0,1>}
EnterDenied
c2 ≤ 1980ms
[not free] /
enterDenied()
{reset: c2}
[c2 ≥ 1s] /
WaitPostAction
c2 ≤ 1s
[free] /
enterAllowed()
{reset: c2}
leaveSection /
request /
{free := int<0,1>}
CheckRequest
c2 ≤ 1980ms
[free] /
EnterAllowed
c2 ≤ 120040ms
enterSection /
confirmEntry()
RailCabOnSection
Figure A.5: Enter Section Protocol’s Roles
122
A.2.2 Normal Track Section
The Normal Track Section contains three ports: left, right, precedingSwitch.
precedingSwitch refines the section role of Next Section protocol. It does not contain
any changes and thereby looks the same as in Figure A.4.
For left and right are refinements of the section role of the Enter Section protocol (see
Figure A.5). Both are implemented the same. Its behavior is shown in Figure A.6.
Additionally, the Normal Track Section contains an inner-behavior illustrated which
shall store whether it is free or occupied Figure A.7.
clock c2
normal_section
Idle
RailCabApproaching
c2 ≤ 1800ms
{free := int<0,1>}
request /
{free := int<0,1>}
[not free] /
CheckRequest
{reset: c2}
[free] /
[free] /
enterAllowed()
EnterAllowed
{reset: c2}
c2 ≤ 120040ms
EnterDenied
c2 ≤ 1980ms
[c2 ≥ 1s]
WaitPostAction
c2 ≤ 1s
leaveSection /
enterSection /
confirmEntry()
RailCabOnSection
Figure A.6: Behavior of Normal Track Section’s left and right port
normal.internal_behavior
Free
/ {sectionFree := false}
Occupied
/ {sectionFree := true}
Figure A.7: Inner-Behavior of Normal Track Section
123
A. Running Example
The dependencies of the scenario can be modeled for Normal Track Section as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/*
* NormalTrackSection :
* (7 Dependencies : 5 Data Assignments ( alternative 5 Enable
Disable or 1 Data Merge ) , 2 Synchronizations
*/
assign precedingSwitch . free := inner . sectionFree };
sync left . CheckRequest (2) --> EnterAllowed ,
right . CheckRequest (2) --> EnterAllowed ,
left . EnterDenied (2) --> EnterAllowed ,
right . EnterDenied (2) --> EnterAllowed with
sync left . WaitPostAction (1) --> Idle ,
right . WaitPostAction (1) --> Idle with
The synthesis of the port behaviors and the inner-behavior regarding the dependencies led to the result shown in Figure A.8. There is no difference between automatic
and manual synthesized component behavior. Again, like within the thesis, green
and red annotated parts are added or removed due to the dependencies.
124
NormalTrackSection
Top State
ch: acquire, release
clock c1
RailCabApproaching
c1 ≤ 1800ms
left
Idle
request /
[not free] /
CheckRequest
{reset: c1}
[free] acquire! /
[free] acquire! /
enterAllowed()
EnterAllowed
{reset: c1}
c1 ≤ 120040ms
EnterDenied
c1 ≤ 1980ms
[c1 ≥ 1s]
release! /
WaitPostAction
c1 ≤ 1s
leaveSection /
enterSection /
confirmEntry()
RailCabOnSection
clock c2
right
Idle
RailCabApproaching
c2 ≤ 1800ms
request /
[not free] /
CheckRequest
{reset: c2}
[free] acquire! /
[free] acquire! /
enterAllowed()
EnterAllowed
{reset: c2}
c2 ≤ 120040ms
EnterDenied
c2 ≤ 1980ms
[c2 ≥ 1s]
release! /
WaitPostAction
c2 ≤ 1s
leaveSection /
precedingSwitch
{reset: c3}
Idle
enterSection /
confirmEntry()
RailCabOnSection
clock c3
Request
Inv: c3<= 500ms
[c3 >= 400ms] /
sectionStatus(free)
internal_behavior
acquire? /
Free
Occupied
release? /
Figure A.8: Normal Track Sections Component’s Behavior
125
A. Running Example
A.2.3 Crossing
The Crossing also contains three ports: left, right, precedingSwitch.
precedingSwitch refines the section role of Next Section protocol. It does not contain
any changes and thereby looks the same as in Figure A.4.
For left and right are refinements of the section role of the Enter Section protocol
(see Figure A.5). They are slightly differently refined. The behavior of the left port
is shown in Figure A.9 and the behavior of the right Figure A.10.
Additionally, the Crossing contains an inner-behavior which shall store whether it
is free or occupied and whether the gates are opening, opened, closing or closed. It
is illustrated in Figure A.11.
variable boolean first
clock c1
crossing.left
Idle
/ newSection()
{reset: c1}
RailCabApproaching
c1 ≤ 100ms
request /
{free := sectionFree;}
[c1 ≥ 1s]
gateOpened?
[not free]
/ enterDenied()
{reset: c1}
WaitOpenGate
c1 ≤ 1s
CheckRequest
c1 ≤ 120ms
[free]
closeGate!
EnterDenied
c1 ≤ 1980ms
openGate!
leaveSection /
confirmExit()
{reset: c1}
RailCabOnSection
[free] / closeGate!
{reset: c1}
ClosingGate
c1 ≤ 1980ms
gateClosed?
/ enterAllowed()
{reset: c1}
enterSection /
confirmEntry()
EnterAllowed
c1 ≤ 120040ms
Figure A.9: Left Port’s Behavior of Crossing
126
variable boolean free, boolean first
clock c2
crossing.right
Idle
/ newSection()
{reset: c2}
RailCabApproaching
c2 ≤ 100ms
request /
{free := int<0,1>}
[c2 ≥ 1s]
WaitOpenGate
c2 ≤ 1s
SendDenial
c2 ≤ 1980ms
[c2 ≥ 1s] [not free]
{free := int<0,1>}
CheckRequest
c2 ≤ 120ms
[not free]
[free]
/ enterDenied()
{reset: c2}
EnterDenied
c2 ≤ 1980ms
ClosingGate
c2 ≤ 1980ms
[free] /
{reset: c2}
leaveSection /
confirmExit()
{reset: c2}
/ enterAllowed()
{reset: c2}
RailCabOnSection
EnterAllowed
c2 ≤ 120040ms
enterSection /
confirmEntry()
Figure A.10: Right Port’s Behavior of Crossing
clock c3
crossing.internal_behavior
/ {reset: c3;}
Closing
c3 ≤ 1800ms
Free
Closed
Opening
c3 ≤ 1800ms
/ {reset: c3}
Figure A.11: Inner-Behavior of Crossing
127
A. Running Example
The dependencies of the scenario can be modeled for Crossing as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/*
* Crossing
* (12 Dependencies : 7 Data Assignments ( alternative 1 Data
Assignment + 6 Data Constraints in short notation just 1
Dependency or 1 Data Merge ) , 4 Synchronizations , 1 Data
Constraint ( can be removed when a Synchronization with
Selector are used ) )
*/
when [ inner . Free (1) --> Closing ] {
assign gateAction := true };
when [ inner . Closed (1) --> Opening ] {
assign gateAction := false };
if [ gateStatus == true ] {
enable inner . Closing (2) --> Closed ;
disable inner . Opening (1) --> Free };
assign precedingSwitch . free := precedingSwitch . obtainStatus
( sectFree :=
inner . sectionFree ) };
sync left . CheckRequest (2) --> ClosingGate , right . CheckRequest (2)
--> ClosingGate ,
left . EnterDenied (2) --> ClosingGate , right . EnterDenied (2) -->
ClosingGate with
inner . Free (1) --> Closing using closeGate ;
sync inner . Closing (2) --> Closed with left . ClosingGate (2) -->
EnterAllowed ,
right . ClosingGate (2) --> EnterAllowed
using gateClosed ;
sync left . RailCabOnSection (1) --> WaitPostAction ,
right . RailCabOnSection (1) --> WaitPostAction with
inner . Closed (1) --> Opening using openGate ;
sync inner . Opening (1) --> Free with
left . WaitPostAction (1) --> Idle ,
right . WaitPostAction (1) --> Idle using gateOpenend ;
and red annotated parts are added or removed due to the dependencies. Because of
the models size, it is split underneath into two parts (see Figure A.13 and ??) for a
better readability.
128
Crossing
Top State
ch: closeGate,
gateClose,
gateOpened,
openGate;
clock c1
left
Idle
/ newSection()
{reset: c1}
RailCabApproaching
c1 ≤ 100ms
request /
[c1 ≥ 1s]
gateOpened?
[not free]
/ enterDenied()
{reset: c1}
WaitOpenGate
c1 ≤ 1s
CheckRequest
c1 ≤ 120ms
[free]
closeGate!
EnterDenied
c1 ≤ 1980ms
[free] / closeGate!
{reset: c1}
openGate!
leaveSection /
confirmExit()
{reset: c1}
ClosingGate
c1 ≤ 1980ms
gateClosed?
/ enterAllowed()
{reset: c1}
RailCabOnSection
enterSection /
confirmEntry()
EnterAllowed
c1 ≤ 120040ms
clock c2
right
Idle
/ newSection()
{reset: c2}
RailCabApproaching
c2 ≤ 100ms
request /
[c2 ≥ 1s]
gateOpened?
WaitOpenGate
c2 ≤ 1s
SendDenial
c2 ≤ 1980ms
CheckRequest
c2 ≤ 120ms
[not free]
[free]
closeGate!
[c2 ≥ 1s] [not free] / / enterDenied()
{free := sectionFree} {reset: c2}
EnterDenied
c2 ≤ 1980ms
[free] / closeGate!
{reset: c2}
openGate!
leaveSection /
confirmExit()
{reset: c2}
ClosingGate
c2 ≤ 1980ms
gateClosed?
/ enterAllowed()
{reset: c2}
RailCabOnSection
enterSection /
confirmEntry()
clock c3
precedingSwitch
{reset: c3}
Idle
EnterAllowed
c2 ≤ 120040ms
Request
Inv: c3<= 500ms
[c3 >= 400ms] /
sectionStatus(free)
internal_behavior
closeGate? /
{gateAction := true;
reset: c4;}
clock c4
Closing
c4 ≤ 1800ms
Free
[gateStatus] gateClosed! /
Closed
[not gateStatus]
gateOpened! /
Opening
c4 ≤ 1800ms
openGate? /
{gateAction := false;
reset: c4}
Figure A.12: Crossing Component’s Behavior
129
A. Running Example
Crossing
Top State
ch: closeGate,
gateClose,
gateOpened,
openGate;
clock c1
left
Idle
/ newSection()
{reset: c1}
RailCabApproaching
c1 ≤ 100ms
request /
[c1 ≥ 1s]
gateOpened?
WaitOpenGate
c1 ≤ 1s
SendDenial
c1 ≤ 1980ms
[not free]
CheckRequest
c1 ≤ 120ms
[free]
closeGate!
EnterDenied
c1 ≤ 1980ms
[free] / closeGate!
{reset: c1}
openGate!
leaveSection /
confirmExit()
{reset: c1}
ClosingGate
c1 ≤ 1980ms
gateClosed?
/ enterAllowed()
{reset: c1}
RailCabOnSection
enterSection /
confirmEntry()
EnterAllowed
c1 ≤ 120040ms
clock c2
right
Idle
/ newSection()
{reset: c2}
RailCabApproaching
c2 ≤ 100ms
request /
[c2 ≥ 1s]
gateOpened?
WaitOpenGate
c2 ≤ 1s
SendDenial
c2 ≤ 1980ms
[not free]
CheckRequest
c2 ≤ 120ms
[free]
closeGate!
EnterDenied
c2 ≤ 1980ms
openGate!
leaveSection /
confirmExit()
{reset: c2}
[free] / closeGate!
{reset: c2}
ClosingGate
c2 ≤ 1980ms
gateClosed?
/ enterAllowed()
{reset: c2}
Figure A.13: Crossing Component’s Behavior Zoom Part 1 of 2
130
Crossing
right
Idle
/ newSection()
{reset: c2}
RailCabApproaching
c2 ≤ 100ms
request /
[c2 ≥ 1s]
gateOpened?
WaitOpenGate
c2 ≤ 1s
SendDenial
c2 ≤ 1980ms
CheckRequest
c2 ≤ 120ms
[not free]
[free]
closeGate!
EnterDenied
c2 ≤ 1980ms
[free] / closeGate!
{reset: c2}
openGate!
leaveSection /
confirmExit()
{reset: c2}
ClosingGate
c2 ≤ 1980ms
gateClosed?
/ enterAllowed()
{reset: c2}
RailCabOnSection
enterSection /
confirmEntry()
clock c3
precedingSwitch
{reset: c3}
Idle
EnterAllowed
c2 ≤ 120040ms
Request
Inv: c3<= 500ms
[c3 >= 400ms] /
sectionStatus(free)
internal_behavior
closeGate? /
{gateAction := true;
reset: c4;}
clock c4
Closing
c4 ≤ 1800ms
Free
[gateStatus] gateClosed! /
Closed
[not gateStatus]
gateOpened! /
Opening
c4 ≤ 1800ms
openGate? /
{gateAction := false;
reset: c4}
Figure A.14: Crossing Component’s Behavior Zoom Part 2 of 2
131
A. Running Example
A.2.4 Switch
The Switch also contains five ports: left, bottom, right, followingSection1, followingSection2.
followingSection1 (and 2) refine the switch role of Next Section protocol (see Figure A.4). It contains an new Notify state between WaitForSection and Idle which is
shown in Figure A.15.
For left, bottom, and right are refinements of the section role of the Enter Section protocol (see Figure A.5). Each uses the same refinement which is shown in
Figure A.16.
Additionally, the Switch contains an inner-behavior which shall store whether it is
free or occupied illustrated in Figure A.17.
switch
/ requestSectionStatus()
{reset: c2}
Idle
clock c2
WaitForSection
Inv: c2<= 550ms
Notify
Inv: c2<= 20ms
{status := sectionStatus.free} {reset:c2}
Figure A.15: followingSection Ports’ Behavior of Switch
132
clock c2
switch
Idle
RailCabApproaching
c2 ≤ 100ms
request
/ {first := true;}
[free] /
{first:= false; reset: c2}
WaitForTrack
c2 ≤ 1900ms
/ {free := false}
[first and (not free)] /
enterDenied() {reset: c2}
EnterDenied
c2 ≤ 1980ms
{free := int<0,1>}
[(not first) and (not free)] /
{reset: c2}
[free] /
EnterAllowed
c2 ≤ 120040ms
[c2 ≥ 1000ms]
WaitPostAction
c2 ≤ 1000ms
CheckRequest
c2 ≤ 1980ms
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
Figure A.16: Left / Bottom / Right Port’s Behavior of Switch
switch.internal_behavior
Free
Occupied
Figure A.17: Inner-Behavior of Switch
133
A. Running Example
The dependencies of the scenario can be modeled for Switch as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/*
* Switch
* (10 Dependencies : 6 Data Assignments , 4 Synchronizations )
* */
when [ ( left . EnterDenied (1) --> EnterDenied or leaving
left . WaitForTrack ) ] {
when [ ( right . EnterDenied (1) --> EnterDenied or leaving
right . WaitForTrack ) ] {
when [ ( bottom . EnterDenied (1) --> EnterDenied or leaving
bottom . WaitForTrack ) ] {
assign bottom . free := inner . sectionFree };
sync left . CheckRequest (1) --> EnterDenied , right . CheckRequest (1)
--> EnterDenied ,
bottom . CheckRequest (1) --> EnterDenied with
sync left . WaitPostAction (1) --> Idle , right . WaitPostAction (1) -->
Idle ,
bottom . WaitPostAction (1) --> Idle with
sync left . RailCabApproaching (1) --> WaitForTrack ,
left . EnterDenied (3) --> WaitForTrack ,
right . RailCabApproaching (1) --> WaitForTrack ,
right . EnterDenied (3) --> WaitForTrack ,
bottom . RailCabApproaching (1) --> WaitForTrack ,
bottom . EnterDenied (3) --> WaitForTrack with
followingSection1 . Idle (1) --> WaitForSection ,
followingSection2 . Idle (1) --> WaitForSection using
nextSectionFree ;
sync left . WaitForTrack (1) --> CheckRequest [ true ] ,
right . WaitForTrack (1) --> CheckRequest [ true ] ,
bottom . WaitForTrack (1) --> CheckRequest [ true ] ,
left . WaitForTrack (2) --> CheckRequest [ false ] ,
right . WaitForTrack (2) --> CheckRequest [ false ] ,
bottom . WaitForTrack (2) --> CheckRequest [ false ] with
followingSection1 . Notify (1) --> Idle [ followingSection1 .
status ] ,
followingSection2 . Notify (1) --> Idle [ followingSection2 .
status ]
using sectionFree [ true ] of type BOOLEAN ;
and red annotated parts are added or removed due to the dependencies. Because
of the models size, it is split underneath into three parts (see Figures A.19 to A.21)
for a better readability.
134
Switch
Top State
ch: nextSectionFree,
sectionFree[BOOLEAN],
acquire,
release;
clock c1
left
Idle
RailCabApproaching
c1 ≤ 100ms
request nextSectionFree!
/ {first := true}
[free] nextSectionFree! /
WaitForTrack
c1 ≤ 1900ms
exit / {free := sectionFree}
sectionFree[false]? / {free := false}
EnterDenied
c1 ≤ 1980ms
CheckRequest
c1 ≤ 1980ms
{reset: c1}
[free] acquire! /
EnterAllowed
c1 ≤ 120040ms
[c1 ≥ 1000ms]
release!
WaitPostAction
c1 ≤ 1000ms
sectionFree[true]?
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
clock c2
bottom
Idle
RailCabApproaching
c2 ≤ 100ms
/ {first := true}
WaitForTrack
c2 ≤ 1900ms
EnterDenied
c2 ≤ 1980ms
CheckRequest
c2 ≤ 1980ms
{reset: c2}
[free] acquire! /
EnterAllowed
c2 ≤ 120040ms
[c2 ≥ 1000ms]
release!
WaitPostAction
c2 ≤ 1000ms
sectionFree[true]?
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
clock c3
right
Idle
RailCabApproaching
c3 ≤ 100ms
/ {first := true}
WaitForTrack
c3 ≤ 1900ms
EnterDenied
c3 ≤ 1980ms
CheckRequest
c3 ≤ 1980ms
{reset: c3}
[free] acquire! /
EnterAllowed
c3 ≤ 120040ms
[c3 ≥ 1000ms]
release!
WaitPostAction
c3 ≤ 1000ms
sectionFree[true]?
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
followingSection1
nextSectionFree? / requestSectionStatus()
{reset: c4}
Idle
clock c4
WaitForSection
Inv: c4<= 550ms
Notify
Inv: c4<= 20ms
sectionFree[status]
followingSection2
{reset: c5}
Idle
clock c5
WaitForSection
Inv: c5<= 550ms
Notify
Inv: c5<= 20ms
sectionFree[status]
internal_behavior
acquire? /
Free
Occupied
release? /
Figure A.18: Switch Component’s Behavior
135
A. Running Example
Switch
Top State
ch: nextSectionFree,
sectionFree[BOOLEAN],
acquire,
release;
clock c1
left
Idle
RailCabApproaching
c1 ≤ 100ms
/ {first := true}
WaitForTrack
c1 ≤ 1900ms
EnterDenied
c1 ≤ 1980ms
CheckRequest
c1 ≤ 1980ms
{reset: c1}
[free] acquire! /
EnterAllowed
c1 ≤ 120040ms
[c1 ≥ 1000ms]
release!
WaitPostAction
c1 ≤ 1000ms
sectionFree[true]?
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
clock c2
bottom
Idle
RailCabApproaching
c2 ≤ 100ms
/ {first := true}
WaitForTrack
c2 ≤ 1900ms
EnterDenied
c2 ≤ 1980ms
{reset: c2}
sectionFree[true]?
CheckRequest
c2 ≤ 1980ms
[free] acquire! /
Figure A.19: Switch Component’s Behavior Zoom Part 1 of 3
136
clock c2
bottom
Switch
Idle
RailCabApproaching
c2 ≤ 100ms
/ {first := true}
WaitForTrack
c2 ≤ 1900ms
EnterDenied
c2 ≤ 1980ms
CheckRequest
c2 ≤ 1980ms
{reset: c2}
[free] acquire! /
EnterAllowed
c2 ≤ 120040ms
[c2 ≥ 1000ms]
release!
WaitPostAction
c2 ≤ 1000ms
sectionFree[true]?
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
clock c3
right
Idle
RailCabApproaching
c3 ≤ 100ms
/ {first := true}
WaitForTrack
c3 ≤ 1900ms
EnterDenied
c3 ≤ 1980ms
WaitPostAction
c3 ≤ 1000ms
followingSection1
CheckRequest
c3 ≤ 1980ms
{reset: c3}
[c3 ≥ 1000ms]
release!
leaveSection /
RailCabOnSection
sectionFree[true]?
[free] acquire! /
EnterAllowed
c3 ≤ 120040ms
enterSection /
confirmEntry()
clock c4
137
A. Running Example
right
Switch
WaitForTrack
c3 ≤ 1900ms
EnterDenied
c3 ≤ 1980ms
CheckRequest
c3 ≤ 1980ms
{reset: c3}
[free] acquire! /
EnterAllowed
c3 ≤ 120040ms
[c3 ≥ 1000ms]
release!
WaitPostAction
c3 ≤ 1000ms
sectionFree[true]?
leaveSection /
RailCabOnSection
enterSection /
confirmEntry()
followingSection1
{reset: c4}
Idle
clock c4
WaitForSection
Inv: c4<= 550ms
Notify
Inv: c4<= 20ms
sectionFree[status]
followingSection2
{reset: c5}
Idle
clock c5
WaitForSection
Inv: c5<= 550ms
Notify
Inv: c5<= 20ms
sectionFree[status]
internal_behavior
acquire? /
Free
Occupied
release? /
138
Appendix B
Catalog of Dependency Kind
On the following pages, you find all identified dependencies. Each dependency kind
contains a number, name, and description. Furthermore, the results of the categorization and evaluation are included in the third row. In the fourth row, there is an
requirement example, which is then shown in the dependency model language and
afterwards how it could be synthesized to a component’s Real-Time Statechart. The
synthesis examples are just one possibility to implement the dependency kinds. In
some cases, there are other possibilities. However, because the dependency language
is close to Real-Time Statechart, those choices are strongly limited.
(1)
(2)
(2a)
(2b)
(2c)
(2d)
(3)
(4)
(5)
(6a)
(6b)
Synchronization
Event Constraint
Required Transition Constraint
Once Required Transition Constraint
Entry- / Exit-Clock Constraint
(7a)
(7b)
(8)
(9)
(10a)
(10b)
(11)
(12)
(13)
(14)
Data Merge
Data Pull
Data Push
Data Constraint
Clock Merge
Clock Reset
Clock Constraint
139
B. Catalog of Dependency Kind
(1)
Problem:
Description:
Group:
Direction:
Importance:
Synchronization
Two regions shall do something synchronously.
This requires that two transitions can only be used synchronously
together. To this end, the enforcement of transition combinations must be enabled. Thinking further, this enables to enforce
state combinations by coupling all incoming or outgoing transitions. This allows to control the parallel regions synchronously.
However, synchronizations are highly limited within Real-Time
Statechart and should be employed carefully.
none
bidirectional
Very High
Example
Informal:
Formal:
Synthesis:
A normal track passes the railcab’s requests synchronously to the
following section.
sync left.Idle(1)-->CheckRequest with
followingSection.Idle(1)-->WaitingAnswer using sync ;
The left region has to wait if the followingSection region is not
ready to receive the sync signal. In addition, the followingSection
region has to wait until the left region fires the signal.
Track
channel: sync;
left
Idle
sync!
request
1
2
Check
Request
1
followingSection
Idle
140
sync?
/ request()
1
Waiting
Answer
(2)
Problem:
Description:
Event Constraint
A transition shall be restrict by other regions’ events.
Transitions or states can depend on events, e.g. transition execution, state entries / exits. Meaning, when a event occurs it
could restrict executions of transitions. It can enable or disable
transitions. Through this, we could, e.g., force an eventually
next state / transition. However, it does not force to leave the
current state. Additionally to the required event, another event
can be used to inverted the effect. It is useful, if the event is not
already specified by a variable.
Group: Constraint Dependency
Direction:
Importance:
unidirectional
Very High
Example
Informal:
Formal:
Synthesis:
When a track receives a request from a railcab, it is allowed to
forward the request to the following section. Furthermore, it is
not allowed to process incoming requests of other sections until
the request check is finished.
if [between right.Idle()-->CheckRequest,
leaving right.CheckRequest] {
enable followingSection.Idle()-->WaitingAnswer ;
disable followingSection.Idle()-->IncomingRequest };
The required event sets a flag to true. This flag is used as a
guard and enables or disables the specified transitions. The flag
is inverted when the exit-state event occurs.
Track
request
/ {flag:=true;}
right
1
Idle
2
2
1
CheckRequest
Exit/{flag:=false;}
Approved
1
followingSection
[flag] / request()
1
Idle
2
[not flag]
request
1
Waiting
Answer
Incoming
Request
141
(2a)
Problem:
A transition shall be restricted to another region’s state’s status.
Description:
Transitions or states can depend on a certain state or state combination status. Therefore, transitions can be restricted such
that certain states have to be active or inactive. This could be
expressed through (2) Event Constraint. However, it might be
useful to use an abbreviated notation, because the event which
inverts the flag could be derived for this sub-kind.
Group:
Direction:
Importance:
Constraint Dependency –> (2) Event Constraint
unidirectional
Low
Example
Informal:
Formal:
Synthesis:
The railcab is only allowed to start driving when it is has the
approval of its track section.
if [ railcab.Approved active ] {
enable drive.Idle(1)-->Driving };
The transition from Idle to Driving requires that the state Approved is active. This is done by an additional variable which is
set to true while the state is active and to false while the state
is inactive. In difference to enforced transition combination, the
transition neither needs to be immediately or eventually be activated.
RailCab
drive
2
[flag]
1
Idle
Driving
1
1
railcab
Approved
1
Waiting
142
Entry/{flag:=true;}
Exit/{flag:=false;}
(2b)
Problem:
A transition shall be restricted once a state was entered / left for
the first time or until this moment.
Description:
Next to the (2a) Required State Constraint there exists the possibility that a certain state must only be visited once to enable
or disable the execution of transitions permanently. This can
be typically used to specify initializations. Because its effect is
infinitely, it must be used very carefully.
Group: Constraint Dependency –> (2) Event Constraint
Direction:
Importance:
unidirectional
Low
Example
Informal:
Formal:
Synthesis:
A railcab must be initialized before it is allowed to drive.
if [ between entering railcab.Initialized , INFINITE ] {
Such a dependency can be synthesized through an additional
variable which is set to true when the required state is entered.
In difference to (2a) Required State Constraint, the flag never
changes again. So, the Initialized state could be left without
effect.
RailCab
drive
2
[flag]
1
Idle
Driving
1
1
railcab
Init
1
Initialized
Entry/{flag:=true;}
143
(2c) Required Transition Constraint
Problem:
Description:
Group:
Direction:
Importance:
A transition shall depend on another transition’s execution.
This is an asynchronous dependency between transitions. A transition of one region requires a certain transition event of another
region. Therefore, the transition can be disabled until the required transition event occurs. When the event occurs, the transition stays enabled until it is used. Thus, it has a consuming
character. In comparison to (2a) Required State Constraint, this
dependency can be used if a state can be entered or left by multiple transitions and an effect is only wanted for one of these
transitions. It is another sub-kind of (2) Event Constraint where
partial information can be derived.
unidirectional
High
Example
Informal:
Formal:
Synthesis:
The followingSection region is only allowed to send at most one
request per request that was received in the right region.
if [ between right.Idle(1)-->CheckRequest ,
followingSection.Idle(1)-->WaitingAnswer ] {
enable followingSection.Idle(1)-->WaitingAnswer };
The transition from Idle to WaitingAnswer requires that previously the transition from Idle to CheckRequest was triggered.
After the transition from Idle to WaitingAnswer has been used,
the activation loses effect through the assignment of the variable
flag to false. This example is similar to (1) Synchronization, but
the region followingSection is allowed to send a request asynchronously.
Track
2
request
/ {flag:=true;}
right
1
Idle
1
1
followingSection
[flag] / request()
{flag:=false;}
1
Idle
144
Check
Request
1
Waiting
Answer
(2d) Once Required Transition Constraint
Problem:
A transition shall require another transition’s execution at least
once.
Description:
As described in the (2b) Once Required State Constraint, we also
can have permanent effects through required transition. This
again could be argued by initialization or other mechanisms
which require that a certain transition is used once and its effect
lasts forever. Thus, it also should be used carefully
Direction:
Importance:
unidirectional
Low
Example
Informal:
Formal:
Synthesis:
The initialization must be complete before the railcab is allowed
to drive. This is indicated by an initComplete message.
if [ between railcab.Initializing(1)-->Idle , INFINITE ] {
The synthesis differs from (2c) Required Transition Constraint
such that it does not reset the flag to false.
RailCab
init
2
Initializing
1
2
initComplete
/ {flag:=true;}
Idle
initFailed
1
drive
[flag]
1
Idle
Driving
1
145
(3)
Problem:
A transition shall require the occurrences of an message sequences.
Description:
Message Sequence Constraints can exist before the state based
design is known, e.g., from the requirement engineering. It specifies a required order of transitions, which sends or consumes messages. A transition could depend on such a message sequence.
A message sequence defines a complex event whose observance
costs large effort. It becomes especially difficult, when it contains
messages from multiple regions. Thus, it should be avoided and
instead expressed through multiple (2) Event Constraints.
Group:
Direction:
Importance:
unidirectional
Medium
Example
Informal:
The railcab is only allowed to drive, when it has sent a request
and received a positive answer. When any other intercepting
message occurs, a new request must be sent.
Formal:
The informal should be mapped to state or transition constraints.
Those already encoded message sequences!
Synthesis:
A synthesis can be done with an auxiliary region. This region
is watching a variable which represents the message sequence.
When the message sequence is not correct, the region returns to
Idle. If the sequence is complete, a flag is used to enable the
transition.
var: int seq:= 0, bool flag:=false;
RailCab
Sequences
[seq==1]
Idle
Request
Send
[seq!=1]
/ {seq:=0;}
2
3
[seq<=10]
/ {seq:=1;}
[seq==11]
/ {flag:=true; seq:=0;}
1
3
Approved
railcab
enterDenied
/ {seq+=100;}
3
drive
Idle
146
2
1
1
Black
Box
/ request()
{seq+=1;}
2
[flag]
/ {flag:=false}
enterAllowed
/ {seq+=10;}
1
Driving
(4)
Entry-/ Exit-Clock Constraint
Problem:
A transition shall depend on another event’s last execution time.
Description:
As states or transitions may have time dependencies to events,
it is useful to specify delays. Precisely, the specification of minimum and maximum delays in relation to events. It can be used
to extend all dependency kinds of (2) Event Constraint by additional clock constraints.
Direction:
Importance:
unidirectional
Medium
Example
Informal:
Formal:
Synthesis:
Crossing can be entered if the gates are already closed for more
than 5 seconds.
if [ gate.ClosedGate active > 5 s ] {
enable left.CheckRequest(1)-->EnterAllowed };
An auxiliary clock is used to specify that the transition from
CheckRequest to EnterAllowed has to wait until the ClosedGate
is active for 5s.
clock: gate;
Crossing
left
2
[flag && gate>5s]
Check
Request
1
1
Enter
Allowed
1
gate
Opened
Gate
1
1
ClosedGate
Entry/{reset:gate; flag:=true;}
Exit/{flag:=false;}
147
(5)
Problem:
A transition shall depend on the number of an event’s occurrence.
Description:
It is possible to limit transitions by upper or lower bounds, e.g.
such that they are only allowed for a certain number of visits.
The counters for such limitations must not be reset by the same
event. This dependency kind is an extension for all (2) Event
Constraints. It extends the consuming characteristics of those
constraints from boolean to integer.
Group:
Direction:
Importance:
unidirectional
Low
Example
Informal:
At most three railcabs are allowed to pass the crossing when the
gates are closed. After that, the gates have to open such that
the pedestrians can pass.
Formal:
if [between left.CheckRequest(1)-->EnterAllowed counted 3 times,
gate.OpenedGate1()-->ClosedGate ]{
disable left.CheckRequest(1)-->EnterAllowed };
Synthesis:
var: int limit:=0;
Crossing
left
Check
Requst
1
Opened
Gate
1
1
Enter
Allowed
1
gate
148
2
[limit<3] / {limit++;}
/ {limit:=0;}
1
Closed
Gate
(6a)
Problem:
Description:
Two states shall be mutually excluded.
The forbidden state combination forbids that specified states are
active at the same time. The forbidden state combination could
be interpreted as a black list. It prevents hazardous state combinations.
Group: State Space Limitation
Direction:
Importance:
bidirectional
Low
Example
Informal:
Formal:
Synthesis:
A section of track must not admit entrance to itself from both
sides simultaneously.
forbid left.EnterAllowed , right.EnterAllowed
It uses an auxiliary region and channels, to prevent the combination even in parallel systems. Thereby, it can conflict with the
synthesis of (1) Synchronization.
Track
3
1
enter?
Vacant
Occupied
1
leave?
2
left
Check
Request
1
Check
Request
1
enter!
EnterAllowed
leave!
1
1
right
enter!
EnterAllowed
leave!
1
149
(6b)
Problem:
Description:
Group:
Direction:
Importance:
The not listed state combinations shall be excluded.
The state space can be limited by a (white) list of allowed state
combinations. Thereby, it spans a subset of the global state
space. It builds the inverse to (6a) Forbidden State Combination.
Depending on the proportional size of the remaining state space,
the white or the black list approach is more compact.
State Space Limitation
bidirectional
Very Low
Example
Informal:
A list of allowed combinations (without the combination of both
EnterAllowed).
Formal:
This requirement can be indirectly described by (6a) Forbidden
State Combination.
Synthesis:
Same synthesis as (6a) Forbidden State Combination.
Track
3
1
enter?
Vacant
Occupied
1
leave?
2
left
Check
Request
1
Check
Request
1
EnterAllowed
leave!
1
1
right
150
enter!
enter!
EnterAllowed
leave!
1
(7a)
Problem:
Description:
Certain message sequences shall be excluded.
Forbidden message sequence can be describe, e.g, with Modal
Sequence Diagrams. They do not consider which states are active they only care about certain message sequences, which may
contain timing constraints. They can block transitions of the orthogonal regions and thereby indirectly reduce the state space.
However, observing message synchronously to prevent certain sequences is hardly possible within a Real-Time Statechart. Thus,
Message Sequence Limitations should be avoided.
Group: Message Sequence Limitation
Direction:
Importance:
uni-/ bidirectional
Low
Example
Informal:
A request has to be forwarded by a track to the next section and
its answer must be forwarded back to the requester. Any other
sequences are forbidden.
Formal:
The requirement can be mapped to (6a) Forbidden State Combinations. States already encoded message sequences!
Synthesis:
An auxiliary region restricts the transitions such that only the
not forbidden message sequences are possible.
Track
channel: m1i, m1o, m2i, m2o, m3i, m3o;
Sequences
m1i?
m1o?
Request
Receive
3
1
m2o? Request
1
Denied
Idle
Request
Forwared
1
m2i?
2
m3o?
left
1
1
Request
Allowed
m1i!
request
m3i?
Check
Request
2
1
Idle
1
Idle
Enter
Allowed
m2o!
/enterDenied()
followingSection
1
m1o!
/ request()
m2i!
enterDenied
m3i!
enterAllowed
2
m3o!
/enterAllowed()
1
Waiting
Answer
2
151
(7b)
Problem:
Description:
Group:
Direction:
Importance:
The not described message sequences shall be excluded.
Allowed Message Sequences can be the example Sequences Diagrams created during the requirement engineering. They describe behavior that must be included. If a complete set of allowed message sequences exists, this can be used to forbid all
other possible combinations. Like (6b) Allowed State Combination, this dependency is only useful when there is a small set
of allowed message sequences or the requirement engineering already provides an almost complete set.
Message Sequence Limitation
uni-/ bidirectional
Very Low
Example
Informal:
Formal:
Synthesis:
The previous requirement of (7a) Forbidden Message Sequence
can also be expressed with allowed message sequences, because
they build the inverse.
Use SDM or map to (6a) Forbidden State Combination.
The result can be the same as (7a) Forbidden Message Sequence.
Track
channel: m1i, m1o, m2i, m2o, m3i, m3o;
Sequences
m1i?
m1o?
Request
Receive
3
1
m2o? Request
1
Denied
Idle
Request
Forwared
1
m2i?
2
m3o?
left
1
1
Request
Allowed
m1i!
request
m3i?
Check
Request
2
1
Idle
1
Idle
152
Enter
Allowed
m2o!
/enterDenied()
followingSection
1
m1o!
/ request()
m2i!
enterDenied
m3i!
enterAllowed
2
m3o!
/enterAllowed()
1
Waiting
Answer
2
(8)
Problem:
Description:
A state’s activity shall be restricted by constraints.
A state could require that it is restricted by clock, data, transition, or state constraints and must be left when the constraint is
no longer fulfilled. The same restrictions could also be applied
on state combinations.
Group: none
Direction:
Importance:
unidirectional
Low
Example
Informal:
A crossing is allowed to start closing the gates while pedestrians
are still on the track, but if they are still on the track after 5
seconds, the gates have to open again.
Formal:
bound gate.GateClosing by [ combination of ( gate.ClosingGate ,
detection.Pedestrians ) active < 5 s ] ;
Synthesis:
The invariant and auxiliary region ensures that after 5 time units
of closing the gate, the state Pedestrians is inactive or the gates
open again.
clock: crit var: bool s1:=false, bool s2:=false;
Crossing
3
Protection
/ {reset:crit}
[s1 && s2]
2
Safe
Unsafe
1
1
[not s1 || not s2]
/ {reset:crit}
2
detection
No
Pedestrian
1
1
gate
Opened
Gate
1
1
Pedestrians
Entry/{s2:=true;}
Exit/{s2:=false;}
GateClosing
Inv: crit < 5s
Entry/{s1:=true;}
Exit/{s1:=false;}
1
153
(9)
Problem:
Description:
Group:
Direction:
Importance:
Data Merge
Data should be synchronously shared between regions.
Two regions contain redundant data or data that has to be kept
in sync. Therefore, it is possible that two variables from different
regions are merge to one shared variable over several regions.
This constellation is critical because it can lead to write conflicts.
But in fact, this is a problem we do not have to consider here, its
handling must be specified in the RTSC semantics. In the case
that only one region writes on the shared variable, the conflicts
cannot occur.
none
bidirectional
Medium
Example
Informal:
Formal:
Synthesis:
The information if the section is free is synchronized in all regions.
datamerge right.secFree , left.secFree ;
The variable secFree is included in both ports (left and right)
and by making it global they use the same variable.
var: bool secFree := false;
Track
var: bool secFree := false; 2
right
Check
Request
1
Enter
Allowed
var: bool secFree := false; 1
left
Check
Request
154
[secFree]
/ {secFree:=false;}
1
Enter
[secFree]
/ {secFree:=false;} Allowed
(10a)
Problem:
Description:
Data Pull
Data should be asynchronously shared between regions.
The Data Pull describes that the region, which requires the data
from another, reads it on demand. A pull could be useful if several variables of different regions are used together to determine
a value. When this calculation is done by (10b) Data Push it
would be inefficient, because any variable change would require
a new calculation even when its result is never used. Another
advantage of Data Pull compared to Push is that the assignment
of a variable stays in the owning region. This provides a better
comprehensibility and maintainability.
Group: Data Assignment
Direction:
Importance:
unidirectional
High
Example
Informal:
Formal:
Synthesis:
A railcab is allowed to drive 80km/h alone, whereas in a convoy, the railcabs are allowed to drive 80km/h plus 10km/h for
each railcab include in the convoy, because they profit from the
slipstream. The maximum speed limit is 160km/h.
when [ drive.Driving(1)-->Driving ] {
assign drive.speedLimit :=
drive.min(160, 80 + 10 * master.convoyMembers) };
The information of how many railcabs are composed in a convoy
(variable convoyMembers of master region) is used to limit the
maximum speed (variable speedLimit of drive region). Therefore,
the drive region, which needs the data, pulls convoyMembers
from master at the moment it is needed.
var: int convoyMembers;
RailCab
op: min(int a, int b); var: int speedLimit; 2
drive
1
Driving
/ {speedLimit:= min(160,
80+10*convoyMembers)}
var: int convoyMembers; 1
master
1
Convoy
2
155
(10b)
Problem:
Description:
Group:
Direction:
Importance:
Data Push
Data should be asynchronously shared between regions.
As described in (10) Data Assignment, an assignment could write
in shared variables. Thereby, the adaptation of a regions variable
can be done remotely in other regions. This can be useful if the
region does not have to consider from where the data comes,
e.g., when several regions provides the data and the region is
only interested in the latest value. The Data Push can have
conditions, e.g., a certain transition or state must be activated
but also all other constraint types are possible.
Data Assignment
unidirectional
Low
Example
Informal:
Formal:
Synthesis:
When a railcab is driving and an emergency occurs, the speed
has to be reduced immediately to zero.
when [ master.Driving(1)-->EmergencyBreak ] {
assign convoy_slave1.speed := 0 };
An assignment is used to immediately change the speed variable
to zero when an emergency stop has to be done. This kind of data
assignment pushes the data when changes occur and thus always
provides the current information. So, the region convoy_slave1
that uses the variable does not require any new assignments to
update its speed variable.
var: int speed;
RailCab
master
/ {speed:=0}
1
Driving
1
convoy_slave1
156
var: int x; 2
Emergency
Break
var: int speed; 1
(11)
Problem:
Description:
Data Constraint
A transition shall be restricted by data.
Data of one region could be used for guards in other regions.
Data Constraints do not exchange data over regions like in the
last three dependency kinds. They are only used to restrict the
behavior of one region in dependence to data of another.
The required adaptation of the Real-Time Statechart is similar
to the (10a) Data Pull, but because the data constraint only
has influences on transition executions and no influences on data
variables, I separate between them.
Group: Constraint Dependency
Direction:
Importance:
unidirectional
High
Example
Informal:
Formal:
The RailCab relies on the GPS and SpeedSensor if their values
differ by more than 5 km/h to calculate the speed. Otherwise, it
only relies on the SpeedSensor data.
if [ SensorMode.abs(GPS.calculatedSpeed SpeedSensor.measuredSpeed) <= 5 ] {
enable SensorMode.Sensor+GPS()-->SensorOnly };
if [ SensorMode.abs(GPS.calculatedSpeed SpeedSensor.measuredSpeed) > 5 ] {
enable SensorMode.SensorOnly()-->Sensor+GPS };
Synthesis:
The state change of the SensorMode depends on the values of
two other regions. It uses the speed values to determine whether
the difference of both sensors is inside a given tolerance.
var: int calculatedSpeed, int measuredSpeed;
RailCab
op: abs(int a); 3
measuredSpeed) <= 5]
Sensor 1
Sensor
+
Only
1
GPS
measuredSpeed) > 5]
GPS
var: int calculatedSpeed 2
SensorMode
SpeedSensor
var: int measuredSpeed 1
157
(12)
Problem:
Description:
Group:
Direction:
Importance:
Clock Merge
A clock should be synchronously shared between regions.
Two regions cannot only contain synchronous data (see (9) Data
Merge), but also synchronous clocks. This change is highly critical, because often properties depend on clocks, and they might
become invalid.
none
bidirectional
Very Low
Example
Informal:
Formal:
Synthesis:
Ten seconds must have passed between the entry of two railcabs
on a switch.
clockmerge right.lastAccess , left.lastAccess ;
The requirement was already implemented for each region on its
own and by making the clock global, it is fulfilled for the whole
component.
clock: lastAccess;
Switch
clock: lastAccess; 2
right
[lastAccess>10s]
Check
Request
1
EnterAllowed
1
Entry/{reset:lastAccess;}
clock: lastAccess; 1
left
[lastAccess>10s]
Check
Request
158
1
EnterAllowed
1
Entry/{reset:lastAccess;}
(13)
Problem:
Description:
Clock Reset
A clock should depend on another region’s event.
Clocks of one region could depend on events of other regions.
Therefore, it must be possible to control the clock remotely. The
reset can be triggered when a certain constraint is true. Such
constraint could be of any type.
This dependency is almost equivalent to (10b) Data Push, but a
clock can only be reset. An equivalent to (10a) Data Pull does
not exist, because we cannot assign values to clocks. Furthermore, it is expected that all resets triggered by the owning region already exist and therefore can be restricted by constraints.
Again, clock manipulations of other regions should be used very
carefully.
Group: none
Direction:
Importance:
unidirectional
Low
Example
Informal:
Formal:
Synthesis:
At the station the doors are opened for 10 seconds. When the
sensors detect an obstacle while the door is still opened, the time
starts from zero again.
when [ sensor.Idle(1)-->Idle ] {
clockreset door.open };
The first part of the requirement was implemented without any
dependency, but the second part relies on the detection of the
sensor. Hence, a reset is added there.
clock: open;
RailCab
door
DoorOpened
Inv: open<=10
[open>=10s]
/ closeDoor()
clock: open; 2
1
1
Door
Closed
/ {reset:open;}
1
sensor
1
Idle
detection
/ {reset:open;}
159
(14)
Problem:
Description:
Group:
Direction:
Importance:
Clock Constraint
A transition shall be restricted by clock constraints.
A region’s transition can have dependencies to clocks of other
regions. This is a similar dependency like (11) Data Constraint,
but instead of data it accesses a clock. In contrast to (4) Entry-/
Exit-Clock Constraint, this constraint require existing clocks and
not auxiliary ones. So, it must not depend on a certain change
event. In fact, it could have a much complexer reset behavior.
Constraint Dependency
unidirectional
Low
Example
Informal:
Formal:
Synthesis:
The railcab’s door is allowed to close when no obstacle is detected
for ten or more seconds.
if [ clock sensor.detect >= 10 s ] {
enable door.DoorOpened(1)-->DoorClosed };
The detect clock is used as a constraint that prevents the door
from closing when the time has not been reached.
clock: detect;
RailCab
2
door
Door
Opened
[detect>=10s]
/ closeDoor()
1
1
clock: detect; 1
sensor
1
Idle
160
Door
Closed
detection
/ {reset:detect;}
Appendix C
Survey Material
In this chapter, the complete survey can be founded in Section C.1. It shows the
offline version of the Google Form, which was used for the evaluation. The detailed
summary of the survey’s results, i.e., the answers of the participants, are described
in Section C.2. It was generate by the Summary of Responses function of Google
Forms.
C.1 Offline Version of the Survey
To reduce the number of pages, the survey can be found in the digital version and
on CD in file /Appendix/OfflineSurvey.pdf.
C.2 Detailed Summary of the Results
To reduce the number of pages, The survey results can be found in the digital version
and on CD in file /Appendix/SurveyResults.pdf.
161
Appendix D
Implementation Details
This chapter includes implementation details of both the Dependency Language and
the Synthesis Algorithm. Their implementation works for MechatronicUML version 0.4.0.20140213259 and requires further QVT-O version 3.4.0 and XText version
2.5.2.
It follows, in Section D.1, first the language’s implementation including the meta
model. In Section D.2 are the transformation rules given.
D.1 Dependency Language
This appendix chapter provides additional information about the dependency language. It begins in Section D.1.1 with a detailed illustration of the its underlaying
meta model. Section D.1.2 then shows the XText Grammar of the dependency language. Finally, Section D.1.3 describes some important technical details that were
required for language’s development.
163
D. Implementation Details
D.1.1 Meta Model
This section shows in Figure D.1 the class diagram of the dependency language’s
meta model. It shows all newly created classes and indicated by light blue additionally the two classes which are used to connect the SynthesizableBehavior class
with MechatronicUML. There are further inheritance and references which are
hidden for simplicity.
In the following all Classes of the Meta Model are shown. It is generated from the
Dependency Language’s Ecore model and includes all references and documentations
which are currently specified therein.
To reduce the number of pages, The meta model classes can be found in the digital
version and on CD in file /Thesis/Appendix-D-single.pdf.
164
Figure D.1: Meta Model of Dependency Language
165
D.1.2 XText Grammar
1
2
3
4
// written by Sebastian Goschin
// Hidden elements can ’ t be used as assignment , so to use
SL_COMMENT and ML_COMMENT the hidden ( WS ) overrides hidden ( WS ,
ML_COMMENT , SL_COMMENT )
// Further this disallows comments that weren ’ t be stored .
grammar de . uni_paderborn . fujaba . muml . DependencyModelLanguage
with de . uni_paderborn . fujaba . muml . ActionLanguage hidden ( WS )
5
6
7
8
9
10
11
12
13
14
15
16
17
import " platform :/ resource / de . uni_paderborn . fujaba . muml .
dependencylanguage / model / dependencylanguage . ecore "
import " http :// www . eclipse . org / emf /2002/ Ecore " as ecore
// import " http :// www . storydriven . org / core /0.3.1" as core
// import " platform :/ resource / org . storydriven . core / model / core .
ecore #// expressions " as expressions
import " platform :/ resource / org . storydriven . core / model / core . ecore
#// expressions / common " as commonExpressions
import " platform :/ resource / de . uni_paderborn . fujaba . muml .
actionlanguage / model / actionlanguage . ecore " as actionlanguage
import " platform :/ resource / de . uni_paderborn . fujaba . muml / model /
muml . ecore #// realtimestatechart " as realtimestatechart
muml . ecore #// types " as types
muml . ecore #// behavior " as behavior
muml . ecore #// component " as component
muml . ecore #// valuetype " as valuetype
muml . ecore #// msgtype " as msgtype
18
19
20
21
22
23
24
DependencyModel returns DependencyModel :
{ DependencyModel }
( comment =( ML_COMMENT | SL_COMMENT ) ) ?
( dependencies += Dependency ( dependencies += Dependency ) *) ?
;
25
26
27
28
29
30
31
// /////////////////////////////////////
// Dependencies
// /////////////////////////////////////
Dependency returns Dependency :
( Synchronization | ForbiddenStateCombination |
ConditionalDependency | BoundedActiveState | DataMerge |
ClockMerge ) ’; ’ ( comment =( ML_COMMENT | SL_COMMENT ) ) ?
;
166
32
33
34
35
36
37
38
39
40
Synchronization returns Synchronization :
(
( ’ sync ’ sendingEvents += Event ( ’ , ’ sendingEvents += Event ) * ’
with ’ receivingEvents += Event ( ’ , ’ receivingEvents += Event )
*)
|
( ’ sync ’ sendingEvents += SynchronizationEvent ( ’ , ’
sendingEvents += SynchronizationEvent ) * ’ with ’
receivingEvents += SynchronizationEvent ( ’ , ’
receivingEvents += SynchronizationEvent ) *)
)
( ’ using ’ channelName = EString ) ? ( ’[ ’ generalSelectorExpression =
Expression ’] ’ ’ of type ’ selectorType =[ types :: DataType ]) ?
;
41
42
43
44
ForbiddenStateCombination returns ForbiddenStateCombination :
’ forbid ’ states +=[ realtimestatechart :: State | QualifiedName ] ( ’
, ’ states +=[ realtimestatechart :: State | QualifiedName ]) +
;
45
46
47
48
BoundedActiveState returns BoundedActiveState :
’ bound ’ states +=[ realtimestatechart :: State | QualifiedName ] ( ’,
’ states +=[ realtimestatechart :: State | QualifiedName ]) * ’ by ’
’[ ’ constraint = ClockCondition ’] ’
;
49
50
51
52
53
54
55
56
57
58
59
60
ConditionalDependency returns ConditionalDependency :
( ’if ’ condition = Condition
’{ ’
effects += Effect ( ’; ’ effects += Effect ) * ( ’; ’) ?
’} ’
)|
( ’ when ’ ’[ ’ event = ComplexEvent ’] ’
’{ ’
effects += LimitedEffect ( ’; ’ effects += LimitedEffect ) * ( ’; ’) ?
’} ’)
;
61
62
63
64
Effect returns Effect :
EnableDisableEffect | DataAssignmentEffect | ClockResetEffect
;
65
66
67
68
LimitedEffect returns Effect :
DataAssignmentEffect | ClockResetEffect
;
69
70
167
71
72
73
EnableDisableEffect returns EnableDisableEffect :
( isEnable ?= ’ enable ’| ’ disable ’) event = Event
;
74
75
76
77
78
79
80
81
82
83
84
85
86
87
DataAssignmentEffect returns DataAssignmentEffect :
’ assign ’ lhs_typedNamedElementExpression =
TypedNamedElementExpression
(
(
assignOperator = AssignOperator rhs_assignExpression =
InitializeExpression
)
|
(
incrementDecrementOperator =
IncrementDecrementOperatorExpression
)
)
;
88
89
90
91
92
// Somewhy reset without an blank does not parse correctly maybe
it is a xtext keyword
ClockResetEffect returns ClockResetEffect :
’ clockreset ’ clocks +=[ realtimestatechart :: Clock | QualifiedName ]
( " ," clocks +=[ realtimestatechart :: Clock | QualifiedName ]) *
;
93
94
95
96
DataMerge returns DataMerge :
’ datamerge ’ variables +=[ behavior :: Variable | QualifiedName ] ( ’ ,
’ variables +=[ behavior :: Variable | QualifiedName ]) + ( ’ to ’
variableName = EString ) ?
;
97
98
99
100
ClockMerge returns ClockMerge :
’ clockmerge ’ clocks +=[ realtimestatechart :: Clock | QualifiedName ]
( " ," clocks +=[ realtimestatechart :: Clock | QualifiedName ]) +
( ’to ’ clockName = EString ) ?
;
101
102
103
104
105
106
107
108
// /////////////////////////////////////
// Events
// /////////////////////////////////////
Event :
TransitionEvent | StateEvent | StateCombinationEvent |
MessageEvent
;
168
109
110
111
112
MessageEvent returns MessageEvent :
kind = MessageEventKind ( port =[ component :: DiscretePort ] ’. ’) ? type
=[ msgtype :: MessageType ]
;
113
114
115
116
TransitionEvent returns TransitionEvent :
transition =[ realtimestatechart :: Transition | QualifiedName ]
;
117
118
119
120
StateEvent returns StateEvent :
kind = StateEventKind state =[ realtimestatechart :: State |
QualifiedName ]
;
121
122
123
124
StateCombinationEvent returns StateCombinationEvent :
kind = StateEventKind ’ combination of ’ states +=[
realtimestatechart :: State | QualifiedName ] ( " ," states +=[
realtimestatechart :: State | QualifiedName ]) +
;
125
126
127
128
SynchronizationEvent returns SynchronizationEvent :
event = Event ’[ ’ selectorExpression = Expression ’] ’
;
129
130
131
132
ComplexEvent returns Event :
( ’( ’ ( CompositionEvent | CountedEvent | DelayedEvent ) ’) ’) |
Event
;
133
134
135
CompositionEvent returns CompositionEvent :
leftEvent = ComplexEvent kind = LogicOperator rightEvent =
ComplexEvent ;
136
137
138
139
CountedEvent returns CountedEvent :
event = ComplexEvent ’ counted ’ counter = EInt ’ times ’
;
140
141
142
143
DelayedEvent returns DelayedEvent :
event = ComplexEvent ’ delayed by ’ delay = TimeValue
;
144
145
146
147
// /////////////////////////////////////
// Dependency Conditions
// /////////////////////////////////////
148
149
150
Condition returns Condition :
CompositionOrCondition
169
151
;
152
153
154
155
ConditionWithoutKeyword returns Condition :
’[ ’( StateStatusCondition | EventConstrainedIntervalCondition
| DataCondition | ClockCondition | CompositionOrCondition )
’] ’
;
156
157
158
159
160
161
CompositionOrCondition returns Condition :
CompositionAndCondition
({ CompositionCondition . leftCondition = current } kind = OrOperator
rightCondition = CompositionOrCondition ) ?
;
162
163
164
165
166
CompositionAndCondition returns Condition :
ConditionWithoutKeyword
({ CompositionCondition . leftCondition = current } kind =
AndOperator rightCondition = CompositionAndCondition ) ?
;
167
168
169
170
171
172
173
174
175
StateStatusCondition returns StateStatusCondition :
(
states +=[ realtimestatechart :: State | QualifiedName ]
|
( ’ combination of ’ states +=[ realtimestatechart :: State |
QualifiedName ] ( " ," states +=[ realtimestatechart :: State |
QualifiedName ]) +)
)
kind = StateStatusKind
;
176
177
178
179
180
181
182
183
184
185
EventConstrainedIntervalCondition returns
EventConstrainedIntervalCondition :
’ between ’
( (( initialEnabled ?= ’ INIT ’ ’ OR ’) fromEvent = ComplexEvent ’ , ’
untilEvent = ComplexEvent )
|
( initialEnabled ?= ’ INIT ’ ’ , ’ untilEvent = ComplexEvent )
|
( fromEvent = ComplexEvent ’ , ’ ( untilEvent = ComplexEvent |
enabledInfite ?= ’ INFINITE ’) )
)
;
186
187
188
ClockCondition returns ClockCondition :
BasicClockCondition | AuxiliaryClockCondition |
HybridClockCondition
170
189
;
190
191
192
193
194
195
AuxiliaryClockCondition returns AuxiliaryClockCondition :
’ last ’ event = ComplexEvent
operator = ComparingOperator
bound = TimeValue
;
196
197
198
199
200
201
HybridClockCondition returns HybridClockCondition :
condition = StateStatusCondition
’ holds since ’ operator = ComparingOperator
bound = TimeValue
;
202
203
204
205
206
207
BasicClockCondition returns BasicClockCondition :
’ clock ’ clock =[ realtimestatechart :: Clock | QualifiedName ]
operator = ComparingOperator
bound = TimeValue
;
208
209
210
211
DataCondition returns DataCondition :
expression = LogicalExpression
;
212
213
214
215
216
217
218
219
// /////////////////////////////////////
// Reused Expressions of ActionLanguage only extended by
QualifiedName References
// /////////////////////////////////////
TypedNamedElementExpression returns actionlanguage ::
TypedNamedElementExpression :
typedNamedElement =[ behavior :: TypedNamedElement | QualifiedName ](
’[ ’ indices += ArithmeticExpression ’] ’) *
;
220
221
222
223
224
225
OperationCall returns actionlanguage :: OperationCall :
operation =[ behavior :: Operation | QualifiedName ] ’( ’
( parameterBinding += ParamaterBinding ( ’ , ’ parameterBinding +=
ParamaterBinding ) * ) ?
’) ’
;
226
227
228
229
230
231
232
// /////////////////////////////////////
// Other Rules
// /////////////////////////////////////
TimeValue returns valuetype :: TimeValue :
value = Expression
unit = TimeUnit
171
233
;
234
235
236
237
238
239
240
// /////////////////////////////////////
// Terminals
// /////////////////////////////////////
terminal NUMBER returns ecore :: EBigDecimal :
INT ’. ’ INT
;
241
242
243
244
245
// DO NOT REMOVE THIS TERMINAL AND DO NOT CHANGE ORDER !!! IT
COULD CREATE AN ERROR WHILE GENERATING .
terminal BOOLEAN returns ecore :: EBoolean :
’ true ’ | ’ false ’
;
246
247
248
249
terminal ID :
’^ ’?( ’a ’ .. ’z ’| ’A ’ .. ’Z ’| ’_ ’) (( ’a ’ .. ’z ’| ’A ’ .. ’Z ’| ’_ ’| ’0 ’ .. ’9 ’) +
(( ’( ’( ’0 ’ .. ’9 ’) + ’) --> ’) ( ’a ’ .. ’z ’| ’A ’ .. ’Z ’| ’_ ’| ’0 ’ .. ’9 ’) +)
?) ?
;
250
251
252
253
254
LONG returns ecore :: ELong :
INT
;
255
256
257
258
QualifiedName :
ID ( ’. ’ ID ) *
;
259
260
261
EString returns ecore :: EString :
STRING | ID ;
262
263
264
EInt returns ecore :: EInt :
’-’? INT ;
265
266
267
268
Literal returns ecore :: EString :
NUMBER | BOOLEAN | INT | STRING | ’ null ’
;
269
270
271
272
273
// TODO Check if microseconds works under linux .
TimeUnit returns valuetype :: TimeUnit :
’ns ’ | ’µs ’ | ’ ms ’ | ’s ’ | ’ min ’ | ’h ’ | ’D ’
;
274
275
276
277
// /////////////////////////////////////
// Enumerations
// /////////////////////////////////////
172
278
279
280
enum OrOperator returns commonExpressions :: LogicOperator :
OR = ’ or ’
;
281
282
283
284
enum AndOperator returns commonExpressions :: LogicOperator :
AND = ’ and ’
;
285
286
287
288
enum LogicOperator returns commonExpressions :: LogicOperator :
OR = ’ or ’ | AND = ’ and ’
;
289
290
291
292
enum ComparingOperator returns commonExpressions ::
ComparingOperator :
EQUAL = ’ == ’ | UNEQUAL = ’ <> ’ | LESS = ’ < ’ | LESS_OR_EQUAL = ’ <= ’ |
GREATER_OR_EQUAL = ’ >= ’ | GREATER = ’ > ’
;
293
294
295
296
enum StateEventKind returns StateEventKind :
ENTRY = ’ entering ’ | EXIT = ’ leaving ’
;
297
298
299
300
enum StateStatusKind returns StateStatusKind :
ACTIVE = ’ active ’ | INACTIVE = ’ inactive ’
;
301
302
303
304
enum MessageEventKind returns MessageEventKind :
CONSUMING = ’ consuming ’ | SENDING = ’ sending ’
;
173
D.1.3 Technical Details
The whole language is integrated with MechatronicUML using the Extension
interface. The meta-model’s root element is called SynthesizableBehavior and it inherits Extension. Thereby, it can be appended at every discrete atomic component.
SynthesizableBehavior further inherits BehavioralElement. Such that, it can contain
a Real-Time Statechart which is used for the inner-behavior specification. Furthermore, SynthesizableBehavior contains a dependency model. This dependency model
is the root for the language it can contain a arbitrary number of Depedencies.
For the implementation of the language it was required to declare the QualifiedName of most elements, especially to reference Transitions which do not have a
SimpleName. QualifiedNames require an IQualifiedNameProvider which constructs
the name for every element. Furthermore, this IQualifiedNameProvider must be
registered in the RuntimeModul, too. Additionally, at every place where QualifiedNames are allowed it must be declared in the grammar using a new defined terminal.
In consequence, the Action Language grammar was partially overwriting to enable
QualifiedNames within Expressions. Lastly, the ScopeProvider requires that it uses
the IQualifiedNameProvider for the creation of the scopes.
These scopes are required for XText’s content assistant and to determine valid elements. In this case, the scope requires to reference elements of the selected atomic
component and its MechatronicUML model. The selection can be determined
through the XText Editors context and directly been set. Thus, it must not be textually specified inside of every dependency model. Therefore, it requires overwriting
the generic IScopeProvider binding and providing an own ScopeProviderFactory in
the RuntimeModule. The Factory enables control of the ScopeProvider creation.
Thereby, the atomic component can be set for each ScopeProvider. The ScopeProvider uses the atomic component to calculate the referenceable elements and
provides for each production rule a specific scope.
Besides, XText allows specification of partial parsing. This is useful if it is required
to map Strings to specific values. Within the grammar, this is only possible for
EEnums, but using ValueConverterService this is also possible for any other type.
Via an ValueConverterService registered in RuntimeModule, it is only required to
write two methods: a parsing and serializing method. This language required the
Service for the specification of java.util.concurrent.TimeUnit because this is not an
EEnum.
174
D.2 Synthesis Algorithm: QVT-O Transformation
D.2 Synthesis Algorithm: QVT-O Transformation
The synthesis algorithm consists of four transformations:
Description
Filename
D.2.1
A library which allows to copy every element
that is contained in a Real-Time Statechart.
lib/RTSC2RTSCdeepContainmentCopy.qvto
D.2.2
The transformation which includes every step SoftwareComponentBehaviorSynthesis.qvto
of the synthesis algorithm.
D.2.3
Synthesis Step 1. It uses the library to copy all CopyRTSCsIntoports’ behaviors into the atomic components’ ComponentRTSC.qvto
behavior.
D.2.4
Synthesis Step 2. It integrates the dependen- WeaveDependenciescies into an existing atomic component behav- IntoRTSC.qvto
ior.
D.2.1 RTSC Copy Library
To reduce the number of pages, the transformation can be found in the digital
version and on CD in file /Appendix/RTSC2RTSCdeepContainmentCopy.qvto.
D.2.2 Synthesis Transformation
version and on CD in file /Appendix/SoftwareComponentBehaviorSynthesis.qvto.
D.2.3 Step 1: Port Behavior Copy Transformation
version and on CD in file /Appendix/CopyRTSCsIntoComponentRTSC.qvto.
D.2.4 Step 2: Dependency Integration Transformation
version and on CD in file /Appendix/WeaveDependenciesIntoRTSC.qvto.
175
Appendix E
CD Content
The attached CD has the following contents:
Thesis
In this folder the print version and digital version of this thesis can
be found. The versions only distinguish in their appendix. In the
digital version every thing is included. Additionally, each Appendix
is also available as a separated file.
Appendix
The single files which where described in the appendix can be found
here.
Latex
This folder includes all Latex sources that were used to create this
thesis. It also includes every graphic.
Plugins
In this folder all Eclipse Plugins that where created in the course
of this thesis can be found.
All files can also be found in the SVN:
https://dsd-serv.cs.uni-paderborn.de/svn/ma-goschin/trunk
177

Synthesis of Extended Hierarchical Real

Transcription

Similar documents

diagram

to Print Brochure

Chempacific Brochuer

Alcohol and Chemical Dependency Treatment Programs

October 13-17, 2014 Information: www.esoa-web.org

Slides of the talk - Centre for Digital Music

the presentation slides of Prof. Setola

Marco Teiber and Thomas JJ Müller

DA Systems gets up close and personal with Nightfreight

Computer Settings For NAUTIKOS