Uncertainty and variability in industry-scale projects: Pearls, perils and pitfalls of Model-Driven Engineering at work

Alfonso Pierantonio
Uncertainty and variability in
industry-scale projects
Pearls, perils and pitfalls of Model-Driven Engineering at work
Università degli Studi dell’Aquila / Italy
Keynote VaMoS’22 – February 25, 2022

2
VaMoS ’22 | Alfonso Pierantonio | alfonso.pierantonio@univaq.it
The state-of-the-art in software abstraction is Model-Driven Engineering
What is model-driven engineering

3
◦ Domains are formalized with modeling notations (metamodels)
◦ Automation underpins different forms of model management

4
 model-to-model transformations
 code generations
 model synchronization
 consistency management
 model differencing & comparison
 coupled evolution
 model repair
 (repository) analysis & analytics
 quality assessment
 etc

5
 model-to-model transformations
 code generations
 model synchronization
 consistency management
 model differencing & comparison
 coupled evolution
 model repair
 (repository) analysis & analytics
 quality assessment
 etc
Models are leveraged to a first-class status!

6
Introduction
◦ What is MDE
Modeling Ecosystems
◦ Co-evolution and consistency management
The ERMES Project
◦ Architecture and objectives
◦ Track plan and control board notations
◦ Bidirectionality and uncertainty
◦ Meta-templating for enforcing metamodel change resilience
Conclusions
Roadmap

Code generation has been one of the
most abused selling arguments for MDE

8
Code generation has been one of the most abused selling arguments
for Model-Driven Engineering
Code generation

10
Code generation has been one of the most abused selling arguments
for Model-Driven Engineering
Whether it held promise, it is uncertain
Niche domains benefit from automated code generation, but that is not
homogenous and often related to domain characteristics rather than
the methodology
Code generation

11
Code generation is a monolithic process based on computationally
deterministic models (e.g., Java-like programs)
Code generation vs Software development

12
Code generation is a monolithic process based on computationally
deterministic models (e.g., Java-like programs)
Software development implies the adoption of a life-cycle model that
must deal at different levels with different forms of uncertainty about
◦ understanding user needs
◦ assessing the technical problems emerging during
design and implementation
◦ handling change requirements due to technological
changes and changes in user needs
Code generation vs Software development

13
Projects are characterized by different forms of complexities induced by
the domain and user needs
How Complexity affects MDE projects

14
◦ Domain complexity impacts on the intricacy of the
metamodel structure and granularity
◦ User needs complexity impacts on the computational
complexity of the model management

15
The more a project is complex, the more sophisticated are the metamodels and
the associated management (transforms, generators, editors)

16
The more a project is complex, the more sophisticated are the metamodels and
the associated management (transforms, generators, editors)
Complexity typically implies
uncertainty in consistency
restoring procedures

17
Similarly to the difference between programming in the large and
programming in the small, we need to consider separately the activities
of modeling in the small and modeling in the large
Modeling in the small / large

18
Modeling in the small typically refers to a simple ecosystem: a limited
number of metaclasses, attributes, references, and (linear)
transformations
Modeling in the small
CIM
Computation
Independent Models
PIM
Platform
Independent Models
PSM
Platform
Specific Models
Code

19
Advanced model-driven techniques applied to an ecosystem consisting
of a coordinated set of metamodels and artifacts that must be kept in a
consistent state
Modeling in the large

20
consistent state
◦ change requirements occurs at architectural and system specification levels
◦ consistency management must be designed

21
consistent state
◦ change requirements occurs at architectural and system specification levels
◦ consistency management must be designed
 complex co-evolution techniques must be devised with an explicit management of
(epistemic) uncertainty, variability models are highly recommended
 whenever possible resilient techniques must be introduced to make processes cost-
effective and reduce ripple effects

22
◦ complex application domain
Modeling in the large / complex domain

23
Modeling in the large / multiple metamodels
Metamodel MM1
Metamodel MM4
Metamodel MM2
Metamodel MM3
◦ multiple interconnected metamodels

24
Modeling in the large / consistency management
Metamodel MM1
Metamodel MM4
Metamodel MM2
Metamodel MM3
D
D
Delta changes
Propagated changes
D
◦ non-univocal consistency restoration

25
Metamodel MM1
Metamodel MM4
Metamodel MM2
Metamodel MM3
D
D
Delta changes
Propagated changes
D
D
D
D
orientation
model

26
Metamodel MM1
Metamodel MM4
Metamodel MM2
Metamodel MM3
D
D
Delta changes
Propagated changes
D
D
D
D
orientation
model

27
Metamodel MM1
Metamodel MM4
Metamodel MM2
Metamodel MM3
D
D
Delta changes
Propagated changes
D
D
D
D
orientation
model
Stevens, P.: Towards sound, optimal, and flexible building
from megamodels. In: ACM/IEEE 21th International Conference on
Model Driven Engineering Languages and Systems (MODELS’18), ACM (2018)

28
Modeling in the large / Modeling ecosystems
Metamodel MM1 Metamodel MM2
transformsTo

29
transformsTo
conformsTo conformsTo

30
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo

31
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo
Generated from the Metamodel
and Concrete Syntax Specification

32
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo
Editor MM2
basedOn
authoredBy

33
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo
Editor MM2
basedOn
authoredBy
Code generator
generates
dependsOn

34
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo
Editor MM2
basedOn
authoredBy
Code generator
generates
D
dependsOn

35
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo
Editor MM2
basedOn
authoredBy
Code generator
generates
D
Metamodel changes might compromise
the integrity and consistency of the
modeling ecosystem
dependsOn

36
transformsTo
conformsTo
Editor MM1
authoredBy
basedOn
conformsTo
Editor MM2
basedOn
authoredBy
generates
D
Di Ruscio, D., Iovino, L., & Pierantonio, A.: Evolutionary togetherness:
how to manage coupled evolution in metamodeling ecosystems. In
International conference on graph transformation (ICGT’12). Springer
Metamodel changes might compromise
the integrity and consistency of the
modeling ecosystem
Code generator
dependsOn

37
What MDE can offer besides code generation?
domain modeling environment
change requirements
validation

The ERMES project
Envisioning Railways Systems through Model-Driven Engineering ApproacheS

40
The railways domain is one of the most constrained – here are some of the
initial difficulties
no overall system requirements
lack of precise concept definitions
the persons who develop interlocking systems have no knowledge of formal methods
we had no knowledge of interlocking systems
The project started in 2018 with an overall duration of 4 + 3 years and
employing
◦ 2 faculties, 4 postdocs, 1 PhD student, 5 MSc
The ERMES project

41
The project aims at building an ecosystem for modeling computer-
based interlocking systems and managing the related life-cycle
The ecosystem is formalized in a megamodel consisting of
◦ a coordinated family of industry-scale modeling notations
◦ model management for letting the ecosystem evolve while
preserving the overall consistency
◦ support tools
 tooling chains at metamodel and model level
 brand-new framework for generating positional / geometric editor
 meta-templating for more «resilient» artifact generation
The ERMES project

42
Architecture
The architecture is arranged in different tiers
ERMES Environment
A meta environment in which the ERMES notation and the related
modeling ecosystem are consistently managed
Modeling Environment
A modeling environment generated from a specific release of the
ERMES notation
Runtime Environment
The deployed operational environment generated for a given station
specified in the Modeling Environment

43
Architecture
ERMES Environment
ERMES notation
Runtime Environment

44
Runtime Environment

45
Runtime Environment

46
Runtime Environment

47
Runtime Environment

48
Runtime Environment
Obtained with the Data
Preparation Process

49
It is the overall process followed to fully configure the station
◦ The final outcome is the configuration of the Safety Logic to be deployed
to the station
Data Preparation Process

50
to the station
Manual intervention needed
for certification reasons

51
to the station

52
Runtime Environment

53
Runtime Environment

54
Architecture
ERMES Environment
ERMES notation
Runtime Environment

57
The track plan notation is given by a metamodel and an associated
concrete syntax that looks like:
The Track Plan notation

58
The track plan notation is given by a metamodel that currently looks like

59
The metamodel is rather complex (as a comparison, UML has 227 classes for 14
diagrams)

60
The first difficulty is given by the complexity of the visual notation
Resorting to the most advanced meta-editors (eg., Sirius) did not help because
they can manage only topological notations
The notation is positional
◦ the semantics of the model depends on the layout
◦ the layout is constraint-based
Because of the metamodel change rate, a new meta-editor has been
designed and implemented

64
The Control Board notation
It is an informative panel used by movement managers for supervising
the operations and simulation purposes, looks like

65
The notion is based on the track plan notation but with differences that
are both structural (in the metamodel) and visual (in the concrete
syntax and layout)

66
Architecture
ERMES Environment
ERMES notation
Runtime Environment

67
Release frequency
Notational changes occurred at a critical rate up to represent a
daunting challenge
In the initial stage of the project, our domain knowledge was
limited, and stakeholders conveyed frequent change
requirements

68
syntax and layout)

69
syntax and layout)
Two-tier automated transformation: abstract
and concrete syntax

70
syntax and layout)
Automated editor generation
from the metamodel and
concrete syntax specification

76
Notational interplay
The track plan notation and the control board counterpart are strictly
related and while the mapping is typically unidirectional there might be
target manual adaptations that must be back-propagated
bidirectional transformation

79
Keeping a set of related models in a consistent state requires back
propagating changes, ie updates to a source entail updates to the
others
◦ Existing languages: OMG QVT, Triple-Graph Grammars, JTL, etc
Notably, a contributory factor limiting the adoption of BX languages is
the assumption that transformations must be deterministic, i.e. one
source model can generate exactly one target model
This is a too strong assumption as often the transformations are
underspecified
Bidiretionality
F. Abou-Saleh, J. Cheney, J. Gibbons, J. McKinna, and P. Stevens. Notions of
BidirectionalComputation and Entangled State Monads. MPC, 2015.

80
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
Authentication Selectingtransaction Transaction
failed
done
shutdown
in(card)
cancel
fault
fixed
Flattening Hierarchical State Machines

81
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
States are propagated

82
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
Outer edges are propagated

83
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
Edges with an inner end are propagated

84
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup

85
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
The «error» edge is manually added
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error

86
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
A such change can be back-propagated?
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error

87
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
A such change can be back-propagated?
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error

88
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
Three valid solutions are possible
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error
error1
error2
error3

89
Such a transformation is non-deterministic that is it does not always
produce a unique solution
◦ the mappings are not injective
◦ multiple update strategies are possible
◦ designers not always hold the information needed for defining a general
consistency-restoration strategy at design-time
It is a form of unknown uncertainty (the designer have not enough
knowledge) that translates into epistemic uncertainty
Bidirectionality
Zan, Tao, Hugo Pacheco, and Zhenjiang Hu.
"Writing bidirectional model transformations as intentional updates." Procs.
36th International Conference on Software Engineering, 2014.

90
The JTL language provide an explicit support to non-determinism
Implementors only need to specify a consistency relation, allowing the
bidirectional engine to resolve the under-specification non-
deterministically
All valid solutions are generated at once
The JTL language
Cicchetti, A., Ruscio, D. D., Eramo, R., & Pierantonio, A., JTL: a bidirectional and
change propagating transformation language. In International Conference on
Software Language Engineering, 2010

91
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Back-propagation
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error
Printing
completed
print
done
Five atomic changes
are performed

92
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Back-propagation
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error
Printing
completed
print
done
#error = 3
error1
error2
error3

93
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
Back-propagation
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error
Printing
completed
print
done
#error = 3
error1
error2
error3

94
Back-propagation
Out of Service
Off Idle
Active
shutdown
cancel
fixed
fault
in(card)
startup
in(card)
Out of Service
Off Idle
Active
shutdown
cancel
fixed
startup
fault
error
Printing
completed
print
done
#error = 3
#done = 1
#print = 4
#completed = 4
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
failed
done
shutdown
in(card)
cancel
fault
fixed
error1
error2
error3
Printing
print1
print2
print3
print4
completed1
completed2
completed3
completed3

95
Little changes in one of the source, cause a combinatorial explosion of
alternatives in the other one
◦ in the previous example, 4 atomic modifications produces 48 models
The number of valid models is unknown before the executions of the
transformation
Little changes, big repercussions
Dealing with a solution made of a myriad of generated models is
intrinsically difficult if not impractical

96
We need a construction that permits an intensional representation of
the solution space
Instead of generating each individual model in the solution space, we
want to represent the solution space of a non-deterministic
transformation with a model with uncertainty
An intensional solution

97
Given a (base) metamodel MM, a corresponding metamodel with
uncertainty U(MM) is obtained by an automated transformation
A model with uncertainty is used to intensionally represent all the models
generated by a non-deterministic transformation

98
Given a (base) metamodel MM, a corresponding metamodel with
uncertainty U(MM) is obtained by an automated transformation
A model with uncertainty is used to intensionally represent all the models
generated by a non-deterministic transformation

99
The JTL engine is based on ASP constraint solver and can derive how
models are related using a deductive process
A fundamental role is played by the tracing information, i.e., the linkage
between the source and target model elements at run-time
Traceability management offers enough information to understand how
the models can be factorized
JTL extention to uncertainty
Eramo, R., Pierantonio, A., & Rosa, G. (2015, October). Managing uncertainty in
bidirectional model transformations. In Proceedings of the 2015 ACM SIGPLAN
International Conference on Software Language Engineering

101
◦ The representation encodes all 48 generated models
◦ In general, not all combinations are admissible, predicates
can be needed to specify inadmissible combinations

102

103

104

105
Introduction
◦ What is MDE
Modeling Ecosystems
◦ Co-evolution and consistency management
The ERMES Project
◦ Architecture and objectives
◦ Track plan and control board notations
◦ Bidirectionality and uncertainty
◦ Meta-templating for enforcing metamodel change resilience
Conclusions
Roadmap

106
Templating Languages
Templating languages, eg. Acceleo, are used for text-generation
Metamodel MM1
conformsTo
Template
generates

107
Metamodel/Template co-evolution
Templating languages, eg. Acceleo, are used for text-generation
Co-evolution scenarios occurs whenever
metamodels are modified
Manual adaptation is prone to
errors and tedious
Automated solutions presents
severe limitations and human intervention
is unavoidable
Limited corpus of research
Metamodel MM1
conformsTo
Template
generates
D
Template
Co-adaptation generates

108
In order to mitigate the difficulties due to the template adaptation in presence
of metamodel changes, we devised a novel technique called meta-templating
It permits to make templates «resilient» to changes, ie. under certain conditions
templates do not need to be adapted
Metatemplates

109
Metatemplates
Meta Template
Engine
MM
Metamodel
Meta Template

110
Metatemplates
Meta Template
Engine
MM
Metamodel
Meta Template
MM-specific
Template

111
Metatemplates
Meta Template
Engine
MM
Metamodel
Meta Template
MM-specific
Template
MM-conformant
Model
Target Artifact

112
MetaTemplating
Meta Template
Engine
MM
Metamodel
Meta Template
MM-specific
Template
MM-conformant
Model
Target Artifact
Meta-level Instance-level

113
MetaTemplating
Meta Templates are written with a
language that can predicate at both
metamodel and model level
A Meta Template can be applied to a
metamodel if the latter has a syntactical
structure compatible with the navigation
expressions occurring in the Meta
Template
Such requirement defines a
Metamodel Typing concept

114
Runtime Environment

116
The Safety Logic must comply with IEC 61508 requirements to minimize
any harmful effects caused by a potential system failure
Safety Integrity Level (SIL 1 – SIL 4) quantifies the reliability degree
achieved by any object that performs a safety-related function
Certification issue

117
The Safety Logic must comply with IEC 61508 requirements to minimize
any harmful effects caused by a potential system failure
Safety Integrity Level (SIL 1 – SIL 4) quantifies the reliability degree
achieved by any object that performs a safety-related function
Certification issue
Because of such requirement (SIL 4) to generate the Safety Logic
Configuration, only human-written rules can be used

Meta Template
Engine
Track Plan
Metamodel
Query Language
Environment
Meta Template
QLE-specific
Template
Track Plan
Model
Query
Language
Environment
Condition Table
Metamodel
Safety Logic
Metamodel
Station
Independent
Rules
Safety Logic
Configuration
Instance-level

Meta Template
Engine
Track Plan
Metamodel
Query Language
Environment
Meta Template
QLE-specific
Template
Track Plan
Model
Query
Language
Environment
Condition Table
Metamodel
Safety Logic
Metamodel
Station
Independent
Rules
Safety Logic
Configuration
Instance-level
The Safety Logic Configuration cannot be generated
in although it would be possible

Meta Template
Engine
Track Plan
Metamodel
Query Language
Environment
Meta Template
QLE-specific
Template
Track Plan
Model
Query
Language
Environment
Condition Table
Metamodel
Safety Logic
Metamodel
Station
Independent
Rules
Safety Logic
Configuration
Instance-level
In order to comply to SIL 4, the Meta Template in is used to generate the
Query Language Environment in which the domain experts only can customize
the generic rules.

122
Conclusion
ERMES Environment
ERMES notation
Runtime Environment

123
Conclusions
It is clearly a modeling in the large scenario
While the typical meta-architecture provided by the generic modeling
platforms offers great opportunity, consistent deployment of model-
driven techniques is challenging
The question to answer is whether it is over-design or a cost-effective
way of dealing with complexity
◦ An empirical evaluation would be needed

124
Complexity is pervasive and occurs at domain and solution level
◦ The railways domain is severely constrained because of a consolidated legacy
practice and safety assurance requirements
◦ The Safety Logic is managed by FBK, a different research group
At the solution level complexity induces uncertainty and variability
◦ In offline processes: uncertainty is managed by a decision-making process
based of domain expertise
◦ In automated processes: uncertainty impact is mitigated by adopting variability
models and by making artifacts more resilient to change requirements
Conclusions

125
The technical maturity of the available tools is questionable
Sirius, the state-of-the-art tool for generating editors is completely inadequate;
it has been already clear at month M4 despite efforts and cooperation with the
tool maintainer
Transformation languages have not fully-fledged programming environments
Scalability is an issue, the way the most crucial metamodels (eg. Safety
Logic) are formalized impacts on the performance
Conclusions
The Safety Logic is formalized by domain experts that faced difficulties in
practicing abstraction, consequently accidental complexity occurred

126
What about the initial difficulties
no overall system requirements
 Stakeholders adopted a strategy to not expose us to the complexity
 Stakeholders' objective is to advance the state-of-the-art
lack of precise concept definitions
 The complete picture is not always clearly defined
the persons who develop interlocking systems have no knowledge of formal
methods
 It considerably improved as domain experts increasingly became fluent with modeling
we had no knowledge of interlocking systems
 We keep fighting
Conclusions

127
A big part of this presentation is based on the
work (and espressos) of many
Vittorio Cortellessa, Francesco Basciani, Mirco Franzago,
Davide Cingolani, Tiziano Lombardi, Romolo Marotta,
Andrea Perelli, Matteo Ricci, Stefano Di Francesco,
Lorenzo Andreoli
Last but not least

129
Primary colors
◦
Secondary colors
Terziary colors
Elements / color scheme
Ottanio
#094F6D
Goldpalm
#F6C35A
Gray
#D9D9D9
Light Azure
#90C5E2
Azure
#55A2D8
Azure
#D9D9D9 / 25%
Green
#D9D9D9 / 25%
Red
#D9D9D9 / 25%

130
Terziary colors
Elements / color scheme / example
Azure
#D9D9D9 / 25%
Green
#D9D9D9 / 25%
Red
#D9D9D9 / 25%
25% trasparency

131
Elements
swish
From this morning session:
Many computerized systems have complex continuous facets of behavior ~ Assaf
Current systems are chaotic but are also event-driven ~ Serge

132
Elements / highlighted boxes
Many computerized systems have complex continuous facets
of behavior ~ Assaf
of behavior ~ Assaf
A short sentence on two
lines
A shorter sentence
keyword

133
Elements / disabled boxes
of behavior ~ Assaf
of behavior ~ Assaf
lines
A shorter sentence
keyword

134
Elements / outlined boxes
of behavior ~ Assaf
of behavior ~ Assaf
lines
A shorter sentence
keyword

135
Elements / arrow set 1

136

137

138

139

140
Elements / patches
A sentence
A multiline
sentence
A multiline
sentence
A sentence

141
A coordinated set of scenes that can be associated with a slide in order
to stress a message, as for instance in the followings
Elements / vignettes 1

142
complexity proposal, question, doubt discussion, explanation discussion
idea, solution data, results, definition idea, opportunity success

143
complexity literature, survey design, data, question, result experiment, empirical
analysis, results cooperation, survey, interview design, execution conclusions, final result

144
Elements / Extras

145
Elements / Letter tags
A A A A A A A A
A B C D E F G I
H L M N O
P Q R S T U V W Z
J K X Y
0 1 2 3 4 5 6 8
7 9
A B C D E F G I
H L M N O
P Q R S T U V W Z
J K X Y
0 1 2 3 4 5 6 8
7 9

146
Elements / submerged icebergs

Uncertainty and variability in industry-scale projects: Pearls, perils and pitfalls of Model-Driven Engineering at work

Recommended

Recommended

More Related Content

Similar to Uncertainty and variability in industry-scale projects: Pearls, perils and pitfalls of Model-Driven Engineering at work

Similar to Uncertainty and variability in industry-scale projects: Pearls, perils and pitfalls of Model-Driven Engineering at work (20)

More from Alfonso Pierantonio

More from Alfonso Pierantonio (16)

Recently uploaded

Recently uploaded (20)

Uncertainty and variability in industry-scale projects: Pearls, perils and pitfalls of Model-Driven Engineering at work

Editor's Notes