Within ModelsWard 2016, just after the opening speech I gave on February 19 in Rome, the opening panel has been about the current maturity of model-driven engineering. I also hosted a poll on twitter on this matter (results are available in this other post).
I’m happy the panelists raised several issues I pointed out myself in the introduction to the conference: as software modelling scientists, we are facing big challenges nowadays, as the focus of modelling is shifting, due to the fact that now software is more and more pervasive, in fields like IoT, social network and social media, personal and wearable devices, and so on.
Panel included the keynote speakers of the conference: Manfred Broy, Paola Inverardi and Lionel Briand, three well known names in the Software Engineering and Modeling community.
Manfred Broy highlighted:
- there is a different between scientific maturity and practical maturity. Sometimes, the latter in companies is far beyond the former.
- a truck company in Germany has been practicing modelling for years, and now has this take on the world: whatever is not in the models, doesn’t exist
- The current challenges are about how to model cyber-physical systems
- The flow of model must be clarified: traceability, refinement, model integration are crucial. You must grant syntactic and semantic coherence
- You also need a coherent infrastructure of tools and artefacts, that grants logic integration. You cannot obtain coherence of models without coherence of tools.
- You need a lot of automation, otherwise you won’t get practical maturity. This doesn’t mean to have end-to-end, or round-trip complete model transformations, but you need to push automaton as much as possible
Lionel Briand clarified that:
- by definition, engineering underpins deep mathematical background as a foundation and implies application of the scientific method to solving problems
- maturity can be evaluated in terms of: how much math underpinning is foundational, how many standards and tools exist and are used, whether the scientific approach is used
- Tools, methods, engineers, and scale of MDE are increasing (aka. MDE is increasingly more difficult to avoid)
- we need to split Domain Engineering (where the problem is) and Support Engineering (where the solution will be)
- MDE is the application of modelling principles and tools to any engineering field
- So: is actually SOFTWARE the main field of interest of model-driven engineering?
- In the modern interpretation of life, covering from smart cities to embedded, wearable, and cyber-physical systems, is the border between the environment and the system still relevant?
- In the future we will need to rely less and less on the “creativity” of engineers when building models, and more and more on the scientific/ quantitative/ empirical methods for building models
Isn’t it the case that the real problem is about the word “modeling”? In any other fields (architecture, mechanics, physics) modelling is implicit and obvious. Why not in our community? At the end, what we want to achieve is to raise abstraction and increase automation, nothing else.
Other issues have been raised too:
- why is there so much difference in attitude towards modelling between Europe and US?
- what’s the role of notations and standards in the success / failure of MDE?