Preface to the 4th International Workshop on Multi‐Level Modelling (MULTI 2017) Tony Clark Sheffield Hallam University, UK Ulrich Frank University of Duisburg-Essen, Germany Manuel Wimmer TU Wien, Austria number of participants was around 20. MULTI 2015 also I. INTRODUCTION spawned a new Wiki for the multi-level modeling research Traditional approaches to modelling systems tend to community: emphasize two-levels: type and instance. Recently, the benefits http://homepages.ecs.vuw.ac.nz/Groups/MultiLevelModeling/ of meta-level access have been argued to be of importance in terms of language definition, particularly in terms of domain- specific languages. The ability to define elements at the meta- The scope of the MULTI workshops includes the following level improves the scope for abstraction, reuse, and ultimately topics: system quality. Providing meta-level access introduces a 1. The exact nature of elements in a multi-level hierarchy number of methodological and technological challenges: how, and whether, to introduce strict separation between levels; how and how best to represent them. to express the relationships between elements at different 2. The importance and role of potency and its variants levels; technologies for expressing multi-level concepts. such a durability and mutability. 3. The structure and labeling of a multi-level modelling The roots of multi-level modelling can be traced back over framework. 15 years to when the first papers on flaws in the OMG’s four 4. Methods and technique for discovering clabjects, level modelling architecture were published. From these roots, specializations and classification relationships. various flavours of multi-level modelling have emerged over 5. Formal approaches to multi-level modelling. time, many with associated supporting tools. Examples include DPF workbench, GModel, Melanee, MetaDepth, Nivel, 6. Experiences and challenges in providing tool support OMME and XModeller. Although these technologies share for multi-level modelling. many common ideas, there are significant differences in the 7. Experiences and challenges in applying multi-level fundamental principles they use to support multi-level modelling techniques to large and/or real world modelling. As a result, the current tool landscape is highly problems. fragmented with different tools designed to serve very different 8. Model management languages (transformation, code purposes. There is also a lack of common multi-level generation etc.) in a multi-level setting. modelling guidelines, educational material and even 9. Criteria and approaches for comparing multi-level terminology. Without a common foundation and an evidence- modelling approaches. base for case studies on the benefits of multi-level modeling, 10. Integration of modelling and programming languages. particularly in industry, it will be difficult for the approach to evolve beyond the currently active research community. II. PAPERS The MULTI series of workshops aims to provide a forum MULTI 2017 attracted 14 submissions and accepted 8 as for advances in the field to be presented and discussed. The full papers and an additional poster. The papers covered a wide first MULTI workshop (www.miso.es/multi/2014/) was held at spectrum of topics related to the multi-level modelling, MODELS 2014 in Valencia and spawned a special theme issue demonstrating that the field is active and has significant of SoSyM. The second (www.miso.es/multi/2015/) and third applicability. The workshop introduced the MULTI challenge MULTI workshops were held at MODELS 2015 in Ottawa and (described below) and included a presentation addressing its at MODELS 2016 in St. Malo respectively. The average issues. A configuration is a physical artifact that is composed of components. A component may be composed of other components or of basic parts. There is a difference between the type of a component and its instances. A component has a weight. A bicycle is built of components like frame, a handle bar, two wheels, etc. A bicycle component is a component. A frame, a fork, a wheel, etc. are bicycle components. Frames and forks exist in various colors. Every frame has a unique serial number. Front wheel and rear wheel must have the same size. Each bicycle has a purchase price and a sales price. There are different types of bicycles for different purposes such as race, mountains, city, etc. A mountain bike or a city bike may have a suspension. A mountain bike makes have a rear suspension. That is not the case for city bikes. A racing fork does not have a suspension. It does not have a mud mount either. A racing bike is not suited for tough terrains. A racing bike is suited for races. It can be used in cities, too. Racing frames are specified by top tube, down tube, and seat tube length. A racing bike can be certified by the UCI. A racing frame is made of steel, aluminum, or carbon. A pro race bike is certified by the UCI. A pro race frame is made of aluminum or carbon. A pro racing bike has a minimum weight of 5200 gr. A carbon frame type allows for carbon or aluminum wheel types only. “Challenger A2-XL” is a pro-racer for tall cyclists. The regular sales price is 4999.00. Some exemplars are sold for a lower price. It is equipped with a Rocket-A1-XL pro race frame. The Rocket-A1-XL has a weight of 920.0 gr. A sales manager may be interested in the average sales price of all exemplars of a certain model and may also be interested in the average sales price of all mountain bikes, all racing bikes etc. Figure 1: The MULTI Challenge (2017) A key problem faced by the MULTI community is one that Urbán and Theisz who propose a modular approach that offers arises from the variety of approaches and definitions for a validation framework. concepts and relationships. The paper Developing an Ontological Sandbox: Investigating Multi-Level Modelling’s Multi-level modelling offers the potential for increased Possible Metaphysical Structures by Partridge, de Cesare, abstraction and reuse when representing data. Such abstraction Mitchell, Gailly and Khan addresses this issue by proposing a is key when aiming to achieve data integration through the structure within which definitions can be constructed and definition of new language features whose property constraints analyzed. apply across type levels. The paper Applying Multi-Level Modeling to Data Integration in Product Line Engineering by System engineering tooling is an area that is highly Nesic and Nyberg describes how power-types can be used in appropriate for the application of multi-level modelling since product-lines to succinctly capture constraints such as tools must manage type-level information as data while at the disjointness and completeness. same time allowing tool-users to manipulate tool data as types. The benefits of the approach together with a proof of concept Working with multi-level models poses an interesting implementation is investigated in the context of model-based challenge since there is no agreed approach to visually present user interface development in the paper A Multi-level Approach and manipulate the many different type levels and their for Model-Based User Interface Development by Bjorn Benner. relationships. The paper An Example Application of a Multi- In addition, tooling must offer a range of user functionality that Level Concrete Syntax Specification with Copy-and-Complete is an extension of that supported by traditional tools, Semantics by Jens Gulden describes the application of a new addressing issues such as: what happens to models and their language (the Topology Type Language) to this problem in instances when type-levels are changed. The paper terms of the step-by-step construction of a multi-level model. Maintenance of Multi-Level Models – An Analysis of The field of multi-level modelling has recently expanded to Elementary Change Operations by Toepel and Benner presents produce several approaches and technologies. Some address a framework within which multi-level model change different problem domains as described by the papers in this functionality can be defined and studied. workshop; some agree on key features and others take Programming languages have provided meta-level features opposing views. There is a need to provide a way of evaluating since the early days of Lisp and Smalltalk. Lisp has run-time the application of multi-level approaches as described in the types and a self-defined interpreter. Smalltalk has meta-classes. paper On Evaluating Multi-Level Modeling by Atkinson and More recent languages, such as Java, have a reflective library Kühne. to inspect the program at run-time. However, the motivation in The poster Extending a UML and OCL Tool for Multi- most cases relates to implementation issues rather than Levels: Applications towards Model Quality Assessment by modelling. The paper DeepRuby: Extending Ruby with Dual Doan and Gogolla shows how the USE tool can be extended to Deep Instantiation by Neumayr, Schuetz, Horner and Schrefl support multi-level modelling. shows how principled multilevel modelling can be implemented in the Ruby programming language. III. MULTI CHALLENGE Multi-level modelling introduces the notion of user-defined Multi-level modelling is an active field with potential to types together with the constraints that classify the instances of provide significant improvements to system engineering. the type. The question of how to check the user-defined type However, it is a challenging area and to date the multi-level constraints is addressed by the paper Validated Multi-Layer community has tended to focus on technology issues making Meta-modeling via Intrinsically Modeled Operations by Mezei, the benefits difficult to appreciate for those outside the field. The MULTI 2017 organizers proposed and presented a challenge based on a real-word scenario, and invited researchers to use the challenge as the basis of concrete contributions that can be used to raise the profile of the field. The challenge was discussed at the workshop whose delegates agreed to refine the details for MULTI 2018 with the aim of attracting as many contributions as possible. The 2017 version of the challenge is shown in figure 1. The challenge is intended as the basis for any multi-level modelling approach providing that concrete benefits can be demonstrated. Multi-level features of any submission to the challenge may include any of the following: knowledge about the domain should be represented at the highest level possible; the model can be a foundation for a software system suited for a wide range of general bicycle stores including specialization to, for example, a dealer of professional racing bikes; associations and constraints should cross levels where appropriate; the integrity of lower levels of the model should be consistent with any changes applied to higher levels; mechanisms should synchronize MLM-based models with code. The following are examples of application-level features of any submission to the challenge: multi-level modelling can be used as a basis for configuration for example every bicycle type except for racing bikes may be equipped with an electric motor and electric bikes need enforced brakes and a battery; as a basis for advanced business analytics, for example find every bicycle type that has an electric motor and that has the least number of sales in 2017; representing business processes in multi-level models, for example order management, such as Customer, Order; addressing behaviour abstraction within multi-level models, for example most dealerships favour their own type of order management process, a multi-level model of an order management process should support the reuse of common aspects of order management and extend/refine them to satisfy particular requirements; generating a bicycle product management system from a multi-level model that uses models@run-time to support the addition of new types of bicycle. The challenge is used as the basis of exemplifying multi- modelling using MultEcore as demonstrated in the MULTI 2017 paper Multilevel Modelling with MultEcore: A Contribution to the MULTI 2017 Challenge by Macías, Rutle and Stolz.