This section describes the technical challenges discussed in both events. We split them up into foundation, domain, and tool challenges, respectively. The categorization is not strict since it does not have crispy boundaries; on the contrary, it is a pragmatic one and aims at facilitating the presentation of the challenges. As a consequence, some challenges necessarily span more than one category.
The majority of the presented challenges are of technical nature, but, as the MDE ecosystem matures and the technical issues are addressed, we believe the social and community challenges will become the critical factors for the success of MDE. The next sections shed some more light on these aspects.
The foundation dimension comprehends all the challenges concerning conceptual and theoretical aspects of MDE, covering all the phases of software development (i.e., modeling, deployment, execution, and maintenance). Modeling is a well-established and successful discipline that has been practiced for decades. As a consequence, there might be good reasons for which companies want to exploit these (long-lived) models posing the question about how do we allow legacy models (and hence legacy modeling formats) to remain in existence. Supporting such tasks can take advantage of modeling itself by allowing legacy models to co-exist with modern modeling technologies. In this context, agile and lean software development is increasingly adopted in the software industry. No matter of fact: This is changing the way software is described. Companies must not move away from modeling, making model-driven development valuable at the age of agile development.
As we will see in the domain challenges section, there is a compelling need to improve the MDE solutions in order to support those processes that intrinsically include also social aspects as in multi-disciplinarity and heterogeneous environments. Thus, proper model management is an increasingly pressing challenge. In this setting, How to transform a software engineer into a system engineer that must be able to combine different types of models leads to an integrated view on a system? How can we virtualize these complex systems that are based on a collection of heterogeneous models?
In systems running in an open environment (i.e., Smart* systems), uncertainty during the design of software models is caused by many design alternatives, incomplete information, conflicting stakeholder opinions. How to use MDE to (i) connect discussion models with software artifacts, (ii) relate different models to different choices, (iii) detect proposed solutions for each choice, (iv) learn a Design Space Exploration specification from proposed solution examples, (v) support fuzzy/naturalistic argumentation, (vi) leverage/integrate flexible modeling tools, are all needed aspects to take into account.
Considering the runtime phase of such systems, and the adaptive nature of most of the complex systems developed in the last years, we can say that software changes are ubiquitous and unavoidable. To manage them, we need to go toward a theory of software agility in MDE able to consider different kinds of maintenance, including repair and improvement, adaptation to a new platform, extension with new functionality, reuse in different contexts, refactoring to make the above kinds of maintenance more accessible). At the same time, we need to introduce theories and techniques able to detect/predict software anomalies and suggest the needed software evolutions.
To automatize and make more powerful all the maintenance solutions, we need to extend the MDE techniques exploiting AI techniques that nowadays are ready to be used for complex and highly dynamic systems. MDE techniques can help in the improvement of AI, machine learning, and other cognification techniques. At the same time, cognification techniques can be exploited to improve and bring quantifiable and perceivable advantages to MDE solutions . Machine learning is a technique that builds on the premise of having a tremendous impact not only on the way software behaves and is realized, but also on society. However, its adoptions requires massive skill sets that current professional profiles fail to meet despite the increasing demand. Machine learning practice would be easier if the learning curve for the needed skills would be more convenient. Model-driven software engineering and human–computer interaction design can help in abstracting machine learning technology and, starting from these abstractions, enabling automated code generation.
Due to the complexity of the targeted systems, there is a strong need to increase the usability of the Model Transformation techniques. Model transformations are cornerstone components of any project adopting model-driven techniques, particularly model-to-model model transformations. Current transformation languages, e.g., ATL, QVT, ETL, Henshin, VIATRA, and Stratego, provide rather powerful features and useful capabilities. However, their current adoption in the industry seems to be marginal when compared to Java and others. Difficulties are related to the semantic intricacy of MTLs that despite their apparent simplicity (which helps introducing subtle critical errors); lack of debugging methods and tools; lack of performance, scalability, and inability to deal even with mid-sized models; little or no support for parallelization, concurrent execution or distribution; and poor interoperability. In the same context, bidirectionality in model transformations is all important as it permits two or more models to remain consistent while they undergo modifications. Current approaches often present idiosyncrasies that prevent the implementors from having complete control on the generated solutions. This is due to difficulties in assuring that a transformation is deterministic, making necessary in a class of problems the explicit management of the uncertainty related to the decision to pick the right solution. Understanding, which are the different application scenarios for deterministic and non-deterministic transformations, may mitigate the difficulties in adopting bidirectionality.
This dimension comprehends all the issues related to the nature of the application domains of the systems developed using MDE. Application domains like automotive, aerospace, nuclear, and healthcare aimed to assure a set of particular properties (i.e., privacy, security, safety). To reduce risks and to ensure that the software developed is reliable, assurance case modeling becomes an important part of the model-driven engineering techniques. At the same time, complex systems that also consider the social aspects (i.e., sociotechnical systems), are composed of different and heterogeneous artifacts. A modeling framework to support the integration of data from sensors, open data, laws, regulations, scientific models (computational and data-intensive sciences), engineering models, and user preferences is needed (i.e., DSLs for sociotechnical integration). Finally, the Internet of Things (IoT) domain represents a great opportunity for model-driven engineering applications in a wide range of domains, e.g., smart cities, smart buildings, industry 4.0, automotive, and health care. The answer that we still have to respond is: Can MDE play a key role in the future of IoT and smart systems?.
For sure, MDE allows coping with the complexity of reality by abstracting the relevant aspects for a particular application into corresponding models. In this respect, an MDE based solution is needed for smart city applications (i.e., in domains like Smart Mobility). MDE is a strategic piece of a framework to realize advanced solutions by taking into account different aspects and stakeholders involved in the smart cities domain. Different views allow for the separation of concerns that, together to a higher level of abstraction, reduce the complexity of dealing with complex systems specification—continuous deployment and adaptation using MDE. The relationships between the views, their corresponding semantics, and the configuration of the different applications/services available in a city, constitute a megamodel . In this dimension, in the last 10 years, various engineering disciplines have emerged and are involved in the engineering process. How to transition from implicit to explicit knowledge about MDE in particular fields (i.e., Cyber-Physical Production Systems)?
Tool and implementation challenges
Lack of good tooling is often mentioned as one key aspect hampering the adoption of MDE. We discussed that potential factors that may favor the adoption of model-driven development include adopting textual languages and treating the code as model, good and easy tooling (like modern IDEs), component-based solutions, and high-quality generated code.
Lots of interesting tools for building visual editors are currently available. Visualization and visual editor frameworks are meant to help with working with complex problems; however, too many difficulties are still encountered when designers use them for real. Thus, understanding the principles of building visual editors or visualization frameworks that can apply to complex problems, and analyzing where do our current frameworks/tools fall short should be a major concern.
Describing a complex system requires modeling different heterogeneous views  that need to be linked although they belong to different steps. Analyzing how to build correspondences among such artifacts and understanding the semantics of such links is important in order to be able to insure traceability from requirements to implementation, and deduce requirements from the system. When several stakeholders are involved, artifacts must be linked to them as well and therefore understand the kind of requirements are existing. In this context, expressing the requirements in a human-readable notation that can be understood by a computer program can be highly relevant as well as and consequently understanding how to make the link among the involved artifact expressing the system and requirements in a same formalism (Single Model Principle).
Over the last decade, scalability has been denoted as one of the main challenges in model-driven engineering [11, 17]. As one participant pointed out, vanilla (out-of-the-box) EMF only works for simple projects. The problem is not just the size of the models but the diversity of artifacts, including models, metamodels, transformations, and dependencies, in any non-trivial project. There is a need to tame the accidental complexity of MDE itself. Running large transformations is as important as running transformations on large and heterogeneous models. Besides this, work on parallel and incremental querying and transformation is needed. In this sense,  defended the need for artifact models. According to  these artifacts should be viewed as data to which apply “classical” data analysis exploitation techniques (e.g., those coming from the information retrieval community).
Also, while participants agreed that we do have a reasonably robust MDE tool infrastructure (e.g., metamodeling and transformation languages), many core MDE aspects could still be improved.  highlighted the need to simplify the creation of proper tool support for executable languages by providing various analysis tools for executable domain-specific modeling languages out of the box based on single formalizations of their execution semantics. Similarly,  proposed a more general formalization of model synchronization and consistency management aspects that could be reused across different tools. This could also help with the challenge of making “chaining transformations” as straightforward as composing functions.
Another discussion point led to the argument that MDE tools should become more intelligent and self-aware. Several AI techniques could be used to cognify model-driven techniques  and to improve the autonomy of MDE tools (e.g., smart model autocompletion). Indeed, more and more MDE tools need to collaborate and agree on how to manage and evolve (runtime) models according to a shared set of goals . Self-explanation capabilities will be critical in this scenario. This would also require considering time and timing issues as a first-class dimension (to be able to reason on when the model changes were done) as described in .