action languages for uml execution: where we are and where we are heading

Action Languages for UML executionWhere we are and where we are heading

Federico Ciccozzi Assistant Professor, Mälardalen University (Sweden)

Contact: [email protected]

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

7

Agenda● 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

8

Background

9

Background

● Software too complex for hand-writing machine code

10

Background


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

11

Background


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

● Programming languages, stars of software engineering from early 70s

13

Background● Software complexity growing very fast

3GLs not enoughMachine-orientedToo prescriptive (not useful for communication)Too specific…

14

Background● Software complexity growing very fast

● 3GLs not enough● Machine-oriented● Too prescriptive (not useful for communication)● Too specific● …

15

Background● 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

16

Background● 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

17

1994

18

UML1.[0-4] (1997-2003)

● Primarily for problem understanding and documentation (descriptive)

19

UML1.[0-4] (1997-2003)


● Practitioner saw possibilities for executing models

20

UML1.[0-4] (1997-2003)


● Practitioner saw possibilities for executing models

But..

21

UML1.[0-4] (1997-2003)

● To execute models you need precise modelling!

22

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

23

Precise modelling?● 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

24



● Answer of practitioners and tool vendors..


3GLs could what UML couldn’t

25



● Answer of practitioners and tool vendors..


● 3GLs could what UML couldn’t

26

3GLs for action code – the less good

● 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?..)

27

3GLs for action code – the less good

● 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?..)

28

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

29

Thereby..

● Tools not fully compliant with the UML standard

● End users forced into a “vendor lock-in” predicament

30

Anyhow..

● If you are here, you see potential in ALs

● Let’s talk about them!

31

”The tale of ALs for UML”● 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


● But (hopefully) a happy ending



33





34





35

1997: Shlaer-Mellor Action Language (SMALL)

● 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..

36

2003

UML 1.5

37

2003

UML 1.5● More precise than previous UML1.x

● UML action semantics

38

2003: Action Specification Language (ASL)

● Part of the OOA tool

● Fairly capable AL for its time

● Not aligned to UML1.5 action semantics

● Development stopped in 2009

39

2004: Platform Independent Action Language (PAL)

● Part of the PathMATE tool

● Still there

● Not aligned to UML1.5 action semantics

40

2005

UML 2.0

41

2005

UML 2.0● (Much) more precise than UML1.5

● First step towards a precise execution semantics

42

2007: OCLX4 action language (OCLX4)

● OCL enriched with meta-actions for changing system state

● Not aligned with UML2 action semantics

43

2007: Action Language for Business Logic (ABL)

● Java-inspired

● Meant to be converted to UML actions

● Includes non-UML concepts

● Not aligned with UML2 action semantics

44

2008: +CAL

● In line with UML1.5 action semantics

● Domain-specific (distributed systems)

45

2009

fUML 1.0

46

2009

fUML 1.0● Foundational Subset for Executable UML

● Finally a precise execution semantics for UML

UML

fUML

47

2009

fUML 1.0● Foundational Subset for Executable UML

● Finally a precise execution semantics for UML

UML

fUMLClasses, activities, composite structures

State-machines,etc..

48

2011: UML Action Language (UAL)

● IBM behind it

● Still there (?)

49

2013 Action Language for Foundational UML (ALF)

● Evolution of UAL

● OMG standard since 2013

● Materialization of great ideas in SMALL (Shlaer-Mellor action language), 15 years later

50

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

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



● Provide fUML, a formal specification of the execution semantics for a subset of UML

● Provide ALF, a textual action language based on fUML

53

ALF: what is it?● 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

54


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



55


UML


● Primary goal: specifying executable behaviors within UML structural model



56

ALF for behaviourALF

UML

57


UML



● ALF has an extended notation to represent structure too


58


UML



● ALF has an extended notation to represent structure too

● It is possible to describe a complete (precise) model entirely using ALF

59

ALF for structure + behaviour

60


61


62

ALF code is a model!

=

63

ALF v1.0.1● Lexical structure

● Punctuation, operators, literals, reserved words..

ExpressionsBehavioural unit that evaluates to a collection of valuesCan have side effects (e.g. change values)

StatementsBehavioural segments producing an effectPrimary units od sequencing and control

UnitsStructural elements (mostly within fUML) for defining structural models

for(Integer i in intList){ x = x + i;}

64



● Expressions● Behavioural unit that evaluates to a collection of values● Can have side effects (e.g. change values)

StatementsBehavioural segments producing an effectPrimary units od sequencing and control



65




● Statements● Behavioural segments producing an effect● Primary units of sequencing and control



66




● Statements● Behavioural segments producing an effect● Primary units of sequencing and control

● Units● Structural elements (mostly within fUML) package Pkg{

active class ClassA{..}}

67

ALF v1.0.1: syntactic conformance

● 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 conformancecomplete action language for representing behaviours within a UML structural model

Extended conformanceincludes structural modelling capabilities (ALF units)

68





● Full conformance● complete action language for representing

behaviours within a UML structural model

Extended conformanceincludes 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)

70

ALF v1.0.1: (execution) semantic conformance

● Interpretive execution● modelling tool directly interprets and executes ALF

Compilative executionmodelling tool compiles ALF and executes it according to the semantics specified in fUMLcontext of the execution of a larger model that may not conform to fUML

Translational executionmodelling tool translates ALF and surrounding UML model into an executable non-UML format, and executes the translation on that platforma.k.a. code generation

71



● Compilative execution● modelling tool compiles ALF and executes it according to

the semantics specified in fUML● context of the execution of the surrounding model may not

conform to fUML

Translational executionmodelling tool translates ALF and surrounding UML model into an executable non-UML format, and executes the translation on that platforma.k.a. code generation

72



● Compilative execution● modelling tool compiles ALF and executes it according to

the semantics specified in fUML● 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

73

ALF standard implementations● ALF reference implementation

● By Ed Seidewitz (basically the father of ALF)● Text-based, terminal● Interpretive execution

74

ALF standard implementations● ALF reference implementation

● By Ed Seidewitz (basically the father of ALF)● Text-based, terminal● Interpretive execution

● ALF implementation in Eclipse/Papyrus ● CEA list (France) in collaboration with Ed Seidewitz● Model-based interpretive execution (MOKA)

75

State-of-the-practice in Industry

● 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 ExpertiseTime

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

78

How do we know (besides experience)?

● 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

79

Scrutinized toolsIBM RSAIBM RSARTEIBM Rational RoseIBM Rational RhapsodyMentorGraphics BridgePointFujabaPapyrus - QompassPapyrus - MokaSyntonyMolizFXUModeldriven.orgIBM TauARTISAN Studio SysymCHESSConformiq DesignerGENCODESparx Enterprise ArchitectBOUMLCameo Simulation toolkitQMTOPCASED Model SimulationSOL SOLoist

DemoclesALF-verifierIPANEMATelelogic TauARTISAN StudioAndroMDAAnylogicCODESIMULINKContext-ServGenerticaGENESYSGentleware PoseidonOMEGA-IFXUML2SCAONIX AMEOSAstah ProfessionalCodeCookerAltova UmodelVisual ParadigmBorland Together ArchitectCompuware OptimalJMagic Draw UML ProfessionalPragsoft UML StudioArgoUMLYatta UML LabMicrosoft 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)

82

ALF..● 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

83

What to do?● 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

84

What to do?● 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

85

MDH contribution● 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(), BitStringLimitations for casting and collections management (all collections currently translated to C++ vectors)

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++



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++



88



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++

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


89

MDH contribution● Standalone solutions for translational execution of ALF to C+

+1. ALF transformation: system defined only in terms of ALF (.alf)

● The complete ALF model is translated to C++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++

● 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 currently translated to C++ vectors)

90

MDH contribution● Type deduction mechanisms

● Dynamic typing● Access to members (e.g., a.b in ALF to a.b or ab or a::b in

C++?)● Imported scopes● Nested scopes● ….

91

MDH contribution● 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

92

Transforming ALF● Transformation steps

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

93


● a.-b. structure transformation ● 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++

94



translated automatically to C++● b’’. Action code in C++ can be

copied to the output code files

95



translated automatically to C++● b’’. Action code in C++ can be

copied to the output code files

● CppTree● Intermediate structural

representation for C++ (Xtend/Java)

● Leverages TypeDeduction

96

Main transformation steps● 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 fileOpaque behaviour in ALF: triggers M2T transformation for translation from ALF to C++.cpp fileOpaque behaviour in other (not supported) languages: no action

97


+ skeleton code

● Check for each UML operation if there is a fine-grained behaviour defined in terms of a UML opaque behaviourOpaque behaviour in C++: copies as it is to resulting .cpp fileOpaque behaviour in ALF: triggers M2T transformation for translation from ALF to C++.cpp fileOpaque behaviour in other (not supported) languages: no action

98


+ 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 it as it is to resulting

.cpp fileOpaque behaviour in ALF: triggers M2T transformation for translation from ALF to C++.cpp fileOpaque behaviour in other (not supported) languages: no action

99


+ skeleton code


.cpp file● Opaque behaviour in ALF: triggers M2T transformation

for translation from ALF to C++ .cpp fileOpaque behaviour in other (not supported) languages: no action

100


+ skeleton code


.cpp file● Opaque behaviour in ALF: triggers M2T transformation

for translation from ALF to C++ .cpp file● Opaque behaviour in other (not supported) language:

no action

101

Solution 1ALF

102

Solution 1ALF

C++

M2T

103

Solution 2ALF

C++

104

Solution 2

M2T

105

Scope● 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

106

Two interesting aspects● Memory management in ALF vs. C++

● Execution semantics misalignment between ALF and C++

107

Memory management in ALF vs. C++

● ALF does not enforce a specific memory management mechanism

Two possibilitiesCreate 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 possibilities1. Create and destroy objects explicitly 2. 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++

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++11Three possibilities:

Allocate basic typed variables on the stack and more complex objects on the heap

Pros: good code performance and easy to implementCons: 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 stackPros: best code performance, can prevent stack overflows and leaks, optimal memory usageCons: complex to implement and maintain

112



● 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 implementCons: no prevention from stack overflows



113




● 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



114




● 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 ● Cons: not optimised memory usage


115




● 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 ● 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

116




● 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

117

Execution semantics misalignment● 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

126

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

127


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

128


● Translating UML/ALF to C++ is almost like translating C++ to C to reuse a C compiler● Do you remember CFront? And what happened with it?

129


● Translating UML/ALF to C++ is almost like translating C++ to C to reuse a C compiler● Do you remember CFront? And what happened with it?

CFront

130

Why didn’t CFront succeed?● Overcomplex generated compiler code

● Suboptimal executables (based on C semantics)

131

Let’s compile models instead

132

Why compiling?● Full control over the manipulations that models undergo

Optimisations based on model semantics

Maximised semantics-preservation from model to executableProduced executables semantically more consistent to source models than with any translational approachConsistency enhances model observability (e.g., model debugging, models@runtime

More predictable generated executablesBoost adoption of UML/ALF for embedded real-time and safety-critical systems

133


● Optimisations based on model semantics

Maximised semantics-preservation from model to executableProduced executables semantically more consistent to source models than with any translational approachConsistency enhances model observability (e.g., model debugging, models@runtime


134



● Maximised semantics-preservation from model to executable● Produced executables semantically more consistent to source

models than with any translational approach● Enhanced model-executable consistency

● Better model observability (e.g., model debugging, models@runtime)


135



● Maximised semantics-preservation from model to executable● Produced executables semantically more consistent to source

models than with any translational approach● 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)

136

Solutions for UML/ALF compilation

137

Solutions for UML/ALF compilation

138

The waving guys● 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

139

Other (to be) hot research topics in UML/ALF execution

● 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)

140

Summarising..

141

(f)UML+ALF = Precise modelling

UMLWell-defined syntax for structural detailsProfiles specific for different concerns/domains in a CPS

ALFWell-defined syntax for algorithmic behavioursPlatform-independent -> deployment to different platforms of the same functions

fUMLWell-defined execution semanticsGives tools for producing predictable software (mission-critical CPS, IoT, safety-critical systems in general)

UML + fUML + ALFconsistent abstract syntaxes (fUML as common base)inter-model consistency by-construction

What’s precise modelling?

• Well-defined abstract syntax for structure

• Well-defined abstract syntax for behaviour

• Well-defined model execution semantics

• Intra-model consistency

142

(f)UML+ALF = Precise modelling● UML

● Well-defined syntax for structural details● Profiles specific for different concerns/domains in a CPS

ALFWell-defined syntax for algorithmic behavioursPlatform-independent -> deployment to different platforms of the same functions








143



● ALF● Well-defined syntax for algorithmic behaviours● Platform-independent -> deployment to different platforms of the same

functions (heterogeneous systems -> CPS)








144





● fUML● Well-defined execution semantics● Gives tools for producing predictable software (mission-critical CPS,

IoT, safety-critical systems in general)







145





● 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)● intra-model consistency by-construction (need support by modelling tool)






146

ALF instead of 3GLs for action code

● 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..)

147

ALF instead of 3GLs for action code

● 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

148

Joint effort● 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 baselineDomain-specific customised variationsSynergic effort between developers, users and researchers from industry and academia is vital

149

Joint effort● 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

150

Thanks for the attention!

Contact: [email protected]

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)

mailto:[email protected]

http://www.es.mdh.se/projects/377-SMARTCore

https://wiki.polarsys.org/Papyrus_IC