Action Languages for UML execution: Where we are and where we are heading

Action Languages for UML execution
Where we are and where we are heading
Federico Ciccozzi
Assistant Professor, Mälardalen University (Sweden)
Contact: federico.ciccozzi@mdh.se

Embedded Systems@MDH
Dependable
systems
Real-time
systems
Robotics and
avionics
Sensor
systems and
health
Software
engineering
Verification
and
validation
Mälardalen University (MDH)
Embedded Systems Research Environment

Embedded Systems@MDH
Dependable
systems
Real-time
systems
Robotics and
avionics
Sensor
systems and
health
Software
engineering
Verification
and
validation
Models, components, MDE, CBSE, UML, ALF...

5
● 15+18 full professors
● 70+ senior researchers (PhDs)
● 80+ PhD students
● Research volume 20 MCAD/yr
● ~80% of research in co-production projects

Companies we work with
● ABB AB ● AbsInt Angewandte Informatik GmbH ● Ada
Core ● Addiva ●Aensys Informatikai ● AICAS GMBH ●
Akhela ● Algo Rego ● Algosystems S.A. ● Alten ● Arcticus
Systems AB ● ATEGO SAS ● Atlas Copco ● Attendo ●
Austrian Institute of Technology ● AVL ● Bexen Cardio ●
Bombardier Transportation ● Bruhnspace AB ● Cambio
Healthcare Systems ● Cea List ● Critical Software ●
CrossControl AB ● Delphi France ● DELTA AB ● Ericsson
AB ● Eskilstuna Elektronikpartner AB ● Etteplan ●
European Aeronautic Defence and Space Company ●
Fonsazione Bruno Kessler ● Giraff AB ● GMV Innovating
Solutions ● Hök instrument AB ● Ingenieria de Sistemas
Intensivos en Software, S.L ● Intecs Informatica e
Tecnologia del Software ● JC Development ● Magillem ●
Maximatecc ● Medfield Diagnostics AB ● Meeq AB ●
Microsoft Sverige ● Motion Control ● Munktell Science Park
● Oilfield Technology Group ● Peerialism ● Physiotest ●
Prevas AB ● Prover
● Qtema ● Quality Pharma ● Quviq ● Resiltech ●
Saab ● Scania ● SEMA-TEC ● SICS Swedish ICT -
the Swedish institute of computer science ●
SignalGeneriX ● SINTEF ● SP Technical Research
Institute of Sweden ● Swedish Defence Research
Agency (FOI) ● Swedsoft ● Svensk Elektronik ● T2
Data ● TATA Consulting Services ● TeliaSonera ●
Thales Alenia Space ● Thales Communications and
Security SAS ● Thales Group ● The Swedish National
Road and Transport Research Institute ● Tidorum ●
Traintic ● TTTech Computertechnik AG ● ULMA
Embedded Solutions ● Vendolocus Development ●
VG Power AB ● Virtual Vehicle ● Vitrociset ● Volvo AB
● Volvo Cars ● Volvo Construction Equipment ● Volvo
Group Trucks Technology ● Västerås Science Park ●
X/Open Company Limited ● Xdin

Agenda
7
● Background
● Why Action Languages (ALs)?
● Some history about ALs for UML
● Introduction on Action Language for Foundational UML (ALF)
● Current support for ALF
● Some experiences from executing ALF
● Future perspectives

Background
9
● Software too complex for hand-writing machine code

Background
10
● Abstraction from programming languages (3GLs) was the
solution 

Background
11
● Abstraction from programming languages (3GLs) was the
solution 
● Programming languages, stars of software engineering
from early 70s

Background
13
● Software complexity growing very fast
3GLs not enough
Machine-oriented
Too prescriptive (not useful for communication)
Too specific
…

Background
14
● Software complexity growing very fast
● 3GLs not enough
● Machine-oriented
● Too prescriptive (not useful for communication)
● Too specific
● …

Background
15
● A solution: Model-Driven Engineering (MDE) 
● More abstraction
● Automation
● Separation of concerns (domain-specific modelling
languages)
● Prescriptive AND descriptive
● Human-oriented
Many general-purpose and domain-specific modelling
languages

Background
16
● A solution: Model-Driven Engineering (MDE) 
● More abstraction
● Automation
● Separation of concerns (domain-specific modelling
languages)
● Prescriptive AND descriptive
● Human-oriented
● Many general-purpose and domain-specific modelling
languages

UML1.[0-4] (1997-2003)
● Primarily for problem understanding and
documentation (descriptive)
18

UML1.[0-4] (1997-2003)
● Practitioner saw possibilities for executing models
19

UML1.[0-4] (1997-2003)
● Practitioner saw possibilities for executing models
But..
20

UML1.[0-4] (1997-2003)
● To execute models you need precise modelling!
21

UML1.[0-4] (1997-2003)
● To execute models you need precise modelling!
● What’s precise modelling?
● Well-defined abstract syntax for modelling structure 
● Well-defined abstract syntax for modelling (algorithmic)
behaviours 
● Intra-model consistency
● Inter-model consistency
● Well-defined model execution semantics 
22

Precise modelling?
23
● UML was not able to describe precise complex behaviours
and did not have well-defined execution semantics
Answer of practitioners and tool vendors..
3GLs (C/C++, Java, …)
3GLs could and we had all the tools for executing them
already

Precise modelling?
24
● Answer of practitioners and tool vendors..
3GLs could what UML couldn’t

Precise modelling?
25
● Answer of practitioners and tool vendors..
● 3GLs could what UML couldn’t

3GLs for action code – the less good
26
● Consistency between action code and surrounding model
(inter-model consistency)
● Hard to check
● Very hard to maintain
● Limited cross-domain reusability (think of CPS, IoT, etc..)
Imagine to write Java actions in Ada structural code…
(Why would you even do that?..)

3GLs for action code – the less good
27
● Consistency between action code and surrounding model
(inter-model consistency)
● Hard to check
● Very hard to maintain
● Limited cross-domain reusability (think of CPS, IoT, etc..)
● Imagine to write Java actions in Ada structural code…
● (Why would you even do that?..)

UML1.[0-4] (1997-2003)
● Tools (e.g., from IBM) start supporting executable
variants of UML
● Executability relied on custom semantics
(implicit profiles) in combination with 3GLs for action
code
28

Thereby..
● Tools not fully compliant with the UML standard
● End users forced into a “vendor lock-in”
predicament
29

Anyhow..
30
● If you are here, you see potential in ALs
● Let’s talk about them!

”The tale of ALs for UML”
31
● No princess nor prince on white horse
● No crystal shoe
But (hopefully) a happy ending
DISCLAIMER 1: The coming list of ALs is not meant to be exhaustive, but
rather significative
DISCLAIMER 2: I won’t touch upon other kinds of textual languages used
with/for UML (e.g., Umple, TextUML, txtUML, ..)

32
● No crystal shoe
● But (hopefully) a happy ending

33
● No crystal shoe

34
● No crystal shoe

1997: Shlaer-Mellor Action Language (SMALL)
35
● The first AL for UML!
● Data flow-based execution similar to fUML
● UML did not have an execution semantics to adhere to
● The language was never implemented in practice..

2003
37
UML 1.5
● More precise than previous UML1.x
● UML action semantics

2003: Action Specification Language (ASL)
38
● Part of the OOA tool
● Fairly capable AL for its time
● Not aligned to UML1.5 action semantics
● Development stopped in 2009

2004: Platform Independent Action Language
(PAL)
39
● Part of the PathMATE tool
● Still there
● Not aligned to UML1.5 action semantics

2005
41
UML 2.0
● (Much) more precise than UML1.5
● First step towards a precise execution semantics

2007: OCLX4 action language (OCLX4)
42
● OCL enriched with meta-actions for changing system
state
● Not aligned with UML2 action semantics

2007: Action Language for Business Logic
(ABL)
43
● Java-inspired
● Meant to be converted to UML actions
● Includes non-UML concepts
● Not aligned with UML2 action semantics

2008: +CAL
44
● In line with UML1.5 action semantics
● Domain-specific (distributed systems)

2009
46
fUML 1.0
● Foundational Subset for Executable UML
● Finally a precise execution semantics for UML
UMLfUML

2009
47
fUML 1.0
● Foundational Subset for Executable UML
● Finally a precise execution semantics for UML
UMLfUML
Classes, activities,
composite structures
State-machines,
etc..

2011: UML Action Language (UAL)
48
● IBM behind it
● Still there (?)

2013 Action Language for Foundational
UML (ALF)
49
● Evolution of UAL
● OMG standard since 2013
● Materialization of great ideas in SMALL (Shlaer-Mellor
action language), 15 years later

The (r)evolution of UML2
● Semantically more precise than previous UML when
it comes to execution
Provide fUML, a formal specification of the executable
semantics for a subset of UML2
Provide ALF, a textual action language based on fUML
50

● Provide fUML, a formal specification of the execution
semantics for a subset of UML
Provide ALF, a textual action language based on fUML
51

● Provide fUML, a formal specification of the execution
semantics for a subset of UML
● Provide ALF, a textual action language based on fUML
52

ALF: what is it?
53
● ALF is a Java-like textual surface representation for UML
Execution semantics is given by mapping ALF's concrete
syntax to the abstract syntax of fUML
Primary goal: specifying executable behaviors within UML
structural model
ALF has an extended notation to represent structure too
It is possible to describe a UML model entirely using ALF

ALF: what is it?
54
● Execution semantics is given by mapping ALF's concrete
Primary goal: specifying executable behaviors within UML
structural model

ALF: what is it?
55
● Primary goal: specifying executable behaviors within
UML structural model

ALF: what is it?
57
● ALF has an extended notation to represent structure too

ALF: what is it?
58
● ALF has an extended notation to represent structure too
● It is possible to describe a complete (precise) model
entirely using ALF

ALF for structure + behaviour
59

60

61

ALF v1.0.1
63
● Lexical structure
● Punctuation, operators, literals, reserved words..
Expressions
Behavioural unit that evaluates to a collection of values
Can have side effects (e.g. change values)
Statements
Behavioural segments producing an effect
Primary units od sequencing and control
Units
Structural elements (mostly within fUML) for defining structural
models
for(Integer i in intList){
x = x + i;
}

ALF v1.0.1
64
● Expressions
● Behavioural unit that evaluates to a collection of values
● Can have side effects (e.g. change values)
Statements
Behavioural segments producing an effect
Primary units od sequencing and control
Units
models
x = x + i;
}

ALF v1.0.1
65
● Expressions
● Statements
● Behavioural segments producing an effect
● Primary units of sequencing and control
Units
models
x = x + i;
}

ALF v1.0.1
66
● Expressions
● Statements
● Behavioural segments producing an effect
● Primary units of sequencing and control
● Units
● Structural elements (mostly within fUML)
package Pkg{
active class ClassA{..}
}

ALF v1.0.1: syntactic conformance
67
● Minimum conformance
● subset of ALF to write textual action language snippets within
a larger graphical UML model
● includes only capabilities available in traditional, procedural
programming language
Full conformance
complete action language for representing behaviours within a
Extended conformance
includes structural modelling capabilities (ALF units)

68
● Full conformance
● complete action language for representing behaviours within
a UML structural model
Extended conformance
includes structural modelling capabilities (ALF units)

69
● Full conformance
● complete action language for representing behaviours within
a UML structural model
● Extended conformance
● includes structural modelling capabilities (ALF units)

ALF v1.0.1: (execution) semantic
conformance
70
● Interpretive execution
● modelling tool directly interprets and executes ALF
Compilative execution
modelling tool compiles ALF and executes it according to the
semantics specified in fUML
context of the execution of a larger model that may not conform to
fUML
Translational execution
modelling tool translates ALF and surrounding UML model into an
executable non-UML format, and executes the translation on that
platform
a.k.a. code generation

conformance
71
● Compilative execution
● modelling tool compiles ALF and executes it according to the
● context of the execution of the surrounding model may not
conform to fUML
Translational execution
modelling tool translates ALF and surrounding UML model into an
executable non-UML format, and executes the translation on that
platform
a.k.a. code generation

conformance
72
● Compilative execution
● modelling tool compiles ALF and executes it according to the
● context of the execution of the surrounding model may not
conform to fUML
● Translational execution
● modelling tool translates ALF and surrounding UML model into
an executable non-UML format, and executes the translation on
that platform
● a.k.a. code generation

ALF standard implementations
73
● ALF reference implementation
● By Ed Seidewitz (basically the father of ALF)
● Text-based, terminal

ALF standard implementations
74
● ALF reference implementation
● By Ed Seidewitz (basically the father of ALF)
● Text-based, terminal
● ALF implementation in Eclipse/Papyrus
● CEA list (France) in collaboration with Ed Seidewitz
● Model-based interpretive execution (MOKA)

State-of-the-practice in Industry
75
● UML-based MDE is still relying on 3GLs for action code
Pragmatism..
Reuse of existing models with PL action code (e.g., C++)
Domain specificity
Expertise
Time

76
● UML-based MDE is still relying on 3GLs for action code
Why?
● Pragmatism..
● Reuse of existing models with 3GLs action code
● Domain specificity
● Expertise
● Time/money

77
and..
● ALs have had a bad reputation!
● Before ALF
● Huge amount of different ALs throughout the years
● No efforts in standard (except OMG)
● No traction from research and practice

How do we know (besides experience)?
78
● Systematic review (SR)
● The first systematic investigation of the states of the
art and practice of the execution of UML models
● Over 4,500 papers and tools were scrutinized
● 70 papers and tools were selected for answering the
research questions that we identified

Scrutinized tools
79
IBM RSA
IBM RSARTE
IBM Rational Rose
IBM Rational Rhapsody
MentorGraphics BridgePoint
Fujaba
Papyrus - Qompass
Papyrus - Moka
Syntony
Moliz
FXU
Modeldriven.org
IBM Tau
ARTISAN Studio Sysym
CHESS
Conformiq Designer
GENCODE
Sparx Enterprise Architect
BOUML
Cameo Simulation toolkit
QM
TOPCASED Model Simulation
SOL SOLoist
Democles
ALF-verifier
IPANEMA
Telelogic Tau
ARTISAN Studio
AndroMDA
Anylogic
CODESIMULINK
Context-Serv
Genertica
GENESYS
Gentleware Poseidon
OMEGA-IFX
UML2SC
AONIX AMEOS
Astah Professional
CodeCooker
Altova Umodel
Visual Paradigm
Borland Together Architect
Compuware OptimalJ
Magic Draw UML Professional
Pragsoft UML Studio
ArgoUML
Yatta UML Lab
Microsoft Visual Studio
Provide execution
Do not provide execution

Results: ALs
● Many solutions leverage non-standard action
languages

Results: fUML
● Very few solutions based on fUML (growing)

ALF..
82
●  Increasing industrial interest
●  Adoption in well-established industrial UML-based
development
● Far from painless and swift
● Use of 3GLs in models deeply rooted in UML-based MDE

What to do?
83
● Introducing such a change with brute force is
unthinkable!
Our goal is to support and boost ALF adoption process
by exploiting ALF as a complement to existing UML-based MDE
processes leveraging programming languages
An example: a process producing executable C++ from UML
with C++ as action code.
Could reuse legacy models (or parts of them)
At the same time, new models (or parts of them) couldb be entirely defined
using UML and ALF

What to do?
84
● Introducing such a change with brute force is
unthinkable!
● Research community must support and boost ALF
adoption process
How?
● Industrial-grade innovation
● Focus on industrial needs
● Constructive rather than disruptive

MDH contribution
85
● Standalone solutions for translational execution of ALF to C++
ALF transformation: system defined only in terms of ALF (.alf)
The complete ALF model is translated to C++
UML-ALF transformation: system modelled with UML (+ profiles),
bodies of operations as opaque behaviours defined in ALF
Opaque behaviours in ALF are translated to C++
Basic support for ALF units
(partially) Namespace, package, class, operation, property
Support for translation of minimum conformance (no complete yet)
Except allInstances(), BitString
Limitations for casting and collections management (all collections
currently translated to C++ vectors)

MDH contribution
86
1. ALF transformation: system defined only in terms of ALF (.alf)
● The complete ALF model is translated to C++
UML-ALF transformation: system modelled with UML (+ profiles),
bodies of operations as opaque behaviours defined in ALF
Opaque behaviours in ALF are translated to C++

MDH contribution
87
2. UML-ALF transformation: system modelled with UML (+ profiles),
operation bodies as opaque behaviours defined in ALF
● Opaque behaviours in ALF are translated to C++

MDH contribution
88
● Basic support for ALF units
● (partially) Namespace, package, class, operation, property

MDH contribution
89
● Basic support for ALF units
● (partially) Namespace, package, class, operation, property
● Support for translation of minimum conformance
● Except allInstances(), BitString
● Limitations for casting and collections management (all collections

MDH contribution
90
● Type deduction mechanisms
● Dynamic typing
● Access to members (e.g., a.b in ALF to a.b or ab or a::b in C++?)
● Imported scopes
● Nested scopes
● ….

MDH contribution
91
● Implementation based on Eclipse/Papyrus Mars 1.0
● Set of Eclipse plugins (solution 1 and 2 are separated)
● Translation as model-to-text transformations in Xtend
● First of its kind

Transforming ALF
92
● Transformation steps
● a.-b. structure transformation
● Solution 1: from ALF units
● Solution 2: external generator

Transforming ALF
93
● b’. Action code in ALF (blocks) is
translated automatically to C++
● Solution 1: stored during structure
transformation and then translated
● Solution 2: UML model is navigated and opaque
behaviours in ALF are translated to C++

Transforming ALF
94
● b’’. Action code in C++ can be copied to
the output code files

Transforming ALF
95
● b’’. Action code in C++ can be copied to
the output code files
● CppTree
● Intermediate structural representation
for C++ (Xtend/Java)
● Leverages TypeDeduction

Main transformation steps
96
● Structural translation: produces corresponding C++
skeleton code
Check for each UML operation if there is a fine-grained
behaviour defined in terms of a UML opaque behaviour
Opaque behaviour in C++: copies as it is to resulting .cpp file
Opaque behaviour in ALF: triggers M2T transformation for
translation from ALF to C++.cpp file
Opaque behaviour in other (not supported) languages: no action

97
skeleton code
● Check for each UML operation if there is a fine-grained
Opaque behaviour in C++: copies as it is to resulting .cpp file

98
skeleton code
● Opaque behaviour in C++: copies it as it is to resulting .cpp file

99
skeleton code
● Opaque behaviour in ALF: triggers M2T transformation for
translation from ALF to C++ .cpp file

100
skeleton code
● Opaque behaviour in ALF: triggers M2T transformation for
translation from ALF to C++ .cpp file
● Opaque behaviour in other (not supported) language: no action

Scope
105
● SMARTCore project (funded by Swedish national agency, KKS)
● Project leader:
● Mälardalen University (Federico Ciccozzi)
● Industrial partners:
● ABB CR (Tiberiu Seceleanu)
● Ericsson AB (Diarmuid Corcoran)
● Alten Sweden (Detlef Scholle)
● Linked to Papyrus Industry Consortium initiative

Two interesting aspects
106
● Memory management in ALF vs. C++
● Execution semantics misalignment between ALF and C++

Memory management in ALF vs. C++
107
● ALF does not enforce a specific memory management mechanism
Two possibilities
Create and destroy objects explicitly
Constrain an object's lifecycle to ”execution locus” unless they are not
explicitly destroyed
If all links to an object are destroyed, object can be re-trieved anytime
using class extent expressions (in C++, ”unreachable" objects and
thereby memory leaks)
No univocal way to to bridge memory management mechanisms in
ALF and C++

108
● ALF does not enforce a specific memory management mechanism
● Two possibilities
1. Create and destroy objects explicitly
2. Constrain an object's lifecycle to ”execution locus” unless they are not
If all links to an object are destroyed, object can be re-trieved anytime
using class extent expressions (in C++, ”unreachable" objects and
thereby memory leaks)
No univocal way to to bridge memory management mechanisms in
ALF and C++

109
● ALF does not enforce a specific memory management mechanisms
● If all links to an object are destroyed, object can be retrieved using
class extent expressions
● in C++, ”unreachable" objects and thereby memory leaks
No univocal way to bridge memory management mechanisms in ALF
and C++

110
● ALF does not enforce a specific memory management mechanisms
● If all links to an object are destroyed, object can be retrieved using
class extent expressions
● in C++, ”unreachable" objects and thereby memory leaks
● No univocal way to bridge memory management mechanisms in
ALF and C++

111
● Our goal was to generate C++ code free from memory
overflows/leaks
For practical reasons (industrial applications), we were restricted to
C++11
Three possibilities:
Allocate basic typed variables on the stack and more complex objects on the
heap
Pros: good code performance and easy to implement
Cons: no prevention from stack overflows
Allocate everything on the heap through ”smart pointers”
Pros: good code performance, medium to implement, prevents stack overflows and memory
leaks
Cons: not optimised memory usage
Perform a smart allocation on heap and stack
Pros: best code performance, can prevent stack overflows and leaks, optimal memory usage
Cons: complex to implement and maintain

112
overflows/leaks
● For practical reasons (industrial applications), we were restricted to
C++11
Three possibilities:
Allocate basic typed variables on the stack and more complex objects on the
heap
Pros: good code performance and easy to implement
Cons: no prevention from stack overflows
leaks

113
overflows/leaks
C++11
● Three possibilities:
● Allocate basic typed variables on the stack and more complex objects on
the heap
● Pros: good code performance and easy to implement
● Cons: no prevention from stack overflows
leaks

114
overflows/leaks
C++11
the heap
● Allocate everything on the heap through ”smart pointers”
● Pros: good code performance, medium to implement, prevents stack overflows
● Cons: not optimised memory usage

115
overflows/leaks
C++11
the heap
● Pros: good code performance, medium to implement, prevents stack overflows
● Perform a smart allocation on heap and stack
● Pros: best code performance, can prevent stack overflows and leaks, optimal memory usage
● Cons: complex to implement and maintain

116
overflows/leaks
C++11
the heap
● Pros: good code performance, medium to implement, prevents stack overflows and memory
leaks
● Perform a smart allocation on heap and stack
● Pros: best code performance, can prevent stack overflows and leaks, optimal memory usage
● Cons: complex to implement and maintain

Execution semantics misalignment
117
● ALF and C++ have different semantics
Translating from one to the other does not bridge this
Ad-hoc solutions can be enforced, but are not optimal
3GL compilers (e.g. for C++) optimise according to 3GL semantics

118
ALF
let a : ClassA = …;
let param : Integer = null;
a.addItem(param);
a.printItems();

119
ALF
let a : ClassA = …;
let param : Integer = null;
a.addItem(param); Execution stops here!
a.printItems();

120
C++
ClassA a = …;
int param = null;
a.addItem(param);
a.printItems();

121
● addItem() is called; there might be a null pointer exception
C++
ClassA a = …;
int param = null;
a.addItem(param);
a.printItems();

122
● Translating from one to the other does not bridge this
Ad-hoc solutions can be enforced, but are not optimal

123
● Ad-hoc solutions need to be enforced, but are not optimal

124
● 3GL compilers unaware of UML/ALF semantics

125
● 3GL compilers unaware of UML/ALF semantics
● 3GL compilers optimise according to 3GL semantics

So..
126
● Code generation is not the best way to go..

So..
127
● Translating UML/ALF to C++ is almost like translating C++ to
C to reuse a C compiler

So..
128
● Do you remember CFront? And what happened with it?

So..
129
● Do you remember CFront? And what happened with it?
CFront

Why didn’t CFront succeed?
130
● Overcomplex generated compiler code
● Suboptimal executables (based on C semantics)

Let’s compile models instead 
131

Why compiling?
132
● Full control over the manipulations that models undergo
Optimisations based on model semantics
Maximised semantics-preservation from model to executable
Produced executables semantically more consistent to source models
than with any translational approach
Consistency enhances model observability (e.g., model debugging,
models@runtime
More predictable generated executables
Boost adoption of UML/ALF for embedded real-time and safety-critical
systems

Why compiling?
133
● Optimisations based on model semantics
Maximised semantics-preservation from model to executable
Produced executables semantically more consistent to source models
Consistency enhances model observability (e.g., model debugging,
models@runtime
systems

Why compiling?
134
● Maximised semantics-preservation from model to executable
● Produced executables semantically more consistent to source models
● Enhanced model-executable consistency
● Better model observability (e.g., model debugging, models@runtime)
systems

Why compiling?
135
● Maximised semantics-preservation from model to executable
● Produced executables semantically more consistent to source models
● Enhanced model-executable consistency
● Better model observability (e.g., model debugging, models@runtime)
● More predictable generated executables
● Boost adoption of UML/ALF for embedded real-time safety-critical
systems (e.g. CPS)

Solutions for UML/ALF compilation
136

Solutions for UML/ALF compilation
137

The waving guys
138
● Who are they?
● Mälardalen University (myself, project leader)
● Alten Sweden AB
● Saab Group – Defence and Security
● Academia-industry cooperative project (2017-2020)
● Swedish national funding
● Goals
● Development of predictable safety-critical software-intensive systems
● Compilation of (f)UML/ALF
● Optimised memory management
● Minimisation of dynamic memory handling
● Optimal allocation on heap and stack
● Driven by model-based analysis

Other (to be) hot research topics in
UML/ALF execution
139
● Ability to execute partial models (early verification)
● Modelling uncertainty (flexible development of CPS, IoT)
● Enhanced observability of model execution
● Enhanced control of model execution
● Support for executing models based on UML profiles
● Integration of UML simulators into heterogeneous (multi-paradigm)
simulation systems (CPS)
● Use of model-reference approaches at runtime (models@runtime)

(f)UML+ALF = Precise modelling
141
UML
Well-defined syntax for structural details
Profiles specific for different concerns/domains in a CPS
ALF
Well-defined syntax for algorithmic behaviours
Platform-independent -> deployment to different platforms of the same
functions
fUML
Well-defined execution semantics
Gives tools for producing predictable software (mission-critical CPS, IoT,
safety-critical systems in general)
UML + fUML + ALF
consistent abstract syntaxes (fUML as common base)
inter-model consistency by-construction
What’s precise modelling?
• Well-defined abstract
syntax for structure
syntax for behaviour
• Well-defined model
execution semantics
• Intra-model consistency

142
● UML
● Well-defined syntax for structural details
● Profiles specific for different concerns/domains in a CPS
ALF
Well-defined syntax for algorithmic behaviours
Platform-independent -> deployment to different platforms of the same
functions
fUML
UML + fUML + ALF
execution semantics

143
● UML
● ALF
● Well-defined syntax for algorithmic behaviours
● Platform-independent -> deployment to different platforms of the same
functions (heterogeneous systems -> CPS)
fUML
UML + fUML + ALF
execution semantics

144
● UML
● ALF
● fUML
● Well-defined execution semantics
● Gives tools for producing predictable software (mission-critical CPS, IoT,
UML + fUML + ALF
execution semantics

145
● UML
● ALF
● fUML
● Well-defined execution semantics
● Gives tools for producing predictable software (mission-critical CPS, IoT,
● UML + fUML + ALF
● consistent abstract syntaxes (fUML as common base)
● intra-model consistency by-construction (need support by modelling tool)
execution semantics

ALF instead of 3GLs for action code
146
● ALF standard action language for UML (and profiles)
● Abstraction
● Model consistency and maintainability (full awareness of
surrounding model elements)
● Model reusability (several targets from same input model)
● Model analisability (simulation, execution, etc..)

ALF instead of 3GLs for action code
147
● ALF standard action language for UML (and profiles)
● Abstraction
● Model consistency and maintainability (full awareness of
surrounding model elements)
● Model reusability (several targets from same input model)
● Model analisability (simulation, execution, etc..)
● Shift to ALF in industrial UML-based MDE leveraging
3GLs for action code is not trivial

Joint effort
148
● A myriad of UML tools in 20 years
● More or less wild customisation, enhancement, creation of
dialects
● Innovation reduced to minimum, portability issues, language
implementations discrepancy, …
● Modelling tool landscape which in many ways contradicts UML's
creed (UNIFICATION)
What do we need?
UML = unification technology  unified intents and efforts
Open-source common baseline
Domain-specific customised variations
Synergic effort between developers, users and researchers from
industry and academia is vital

Joint effort
149
● A myriad of UML tools in 20 years
● More or less wild customisation, enhancement, creation of
dialects
● Innovation reduced to minimum, portability issues, language
implementations discrepancy, …
● Modelling tool landscape which in many ways contradicts UML's
creed (UNIFICATION)
● What do we need?
● UML = unification technology  unified intents and efforts
● Common baseline
● Domain-specific customised variations (even user-defined)
● Synergic effort between developers, users and researchers from
industry and academia is vital

Thanks for the attention!
150Contact: federico.ciccozzi@mdh.se
Acknowledgements
Thanks for fruitful discussions and cooperation to:
• Bran Selic (Malina Software Corp.)
• Ivano Malavolta (Vrije University)
• Mikael Sjödin (MDH)
• Alfonso Pierantonio (University of L’Aquila)
• Antonio Cicchetti (MDH)
• Francis Bordeleau (Ericsson)
• Diarmuid Corcoran (Ericsson)
• Thomas Åkerlund (Knightec)
• Alessio Bucaioni (MDH)
• Detlef Scholle (Alten Sweden)
• Tiberiu Seceleanu (ABB Corporate Research)
• SMARTCore (www.es.mdh.se/projects/377-SMARTCore)
• Papyrus IC (wiki.polarsys.org/Papyrus_IC)

Action Languages for UML execution: Where we are and where we are heading

More Related Content

Similar to Action Languages for UML execution: Where we are and where we are heading (20)

Recently uploaded (20)

Action Languages for UML execution: Where we are and where we are heading

Editor's Notes