A Multi-level Approach for Model-Based User Interface Development Björn Benner Information Systems and Enterprise Modeling, University of Duisburg-Essen, Essen, Germany Email: bjoern.benner@uni-due.de Abstract—Multi-level modeling is considered to provide ad- into the dependent models. Therefore, the capabilities for vancements over the traditional modeling approaches. It is integration can support the mutual synchronization of models, applicable, among others, to scenarios where more than two thus, support the overall integrity. Furthermore, MBUID would classification levels are required and a rigid dichotomy between classes and objects needs to be relaxed. As the Model-Based benefit from the increased capabilities of reuse, as it is not User Interface Development (MBUID) inherently encompasses desirable to create each UI from scratch. more than two classification levels, there are challenges which Therefore, our goal is to investigate the applicability of the cannot be accounted for with the traditional approaches (e.g., multi-level paradigm for the model-based development of UIs. the propagation of changes or the extensibility of modeling To the best of our knowledge, only one approach exists that languages). Therefore, it seems promising to apply multi-level modeling for overcoming these challenges. In this paper, we applied multi-level modeling for model-based development show the applicability of the multi-level modeling language of UIs [10]. However, this approach targets the development FMMLx and the language execution engine XModeler for the of concrete syntaxes and is limited by a predefined set of MBUID-field. As a proof of concept, a corresponding prototype visualization types. Therefore, this approach investigates only based on FMMLx and XModeler is presented which illustrates a small subset of the MBUID area. In contrast, we do not only the benefits of multi-level modeling. Index Terms—Multi-level Modeling, MBUID, FMMLx , XMod- focus on the design of UIs, but consider also the other aspects eler of the UI’s entire lifecycle, i.e., its execution, its modification as well as its adaption. Therefore, we investigated not only the I. I NTRODUCTION applicability of multi-level modeling but also the applicability of multi-level programming for MBUID approaches. Hence- Multi-level modeling aims at providing benefits over tradi- forth, the combination of multi-level modeling with multi- tional conceptual modeling, e.g., by supporting an arbitrary level programming is understood as the multi-level paradigm. number of classification levels, increased capabilities of reuse Accordingly, the traditional paradigm is understood as the and increased capabilities of integration [1]. Recently, the traditional conceptual modeling in combination with prevalent interest in multi-level modeling has increased [1]–[4] and programming languages. various multi-level modeling approaches have been success- In order to accomplish the above-mentioned goal, the re- fully applied in different areas, e.g., the management of IT- maining of the paper is structured as follows: First, generic infrastructure [5] or the process improvement in the automo- requirements towards the model-based development of UIs are tive domain [6]. identified (Section II). Afterwards, the approaches based on the Taking into account, on the one hand, characteristics of traditional paradigm are evaluated against those requirements traditional conceptual modeling, on the other hand, unful- (Section III). Following, a multi-level approach is selected filled requirements (e.g., the propagation of changes or the and the suitability of it for satisfying these requirements is extensibility of modeling languages), an additional area which discussed (Section IV). Afterwards, a corresponding prototype seems to be promising as a further field for the application is developed (Section V) and a evaluation takes place (Sec- of multi-level modeling is the Model-Based User Interface tion VI). Finally, conclusions and an outlook on future work Development (MBUID) [7], [8]. MBUID utilizes different are given (Section VII). types of models (e.g., abstract user interface, concrete user interface or final user interface) for the development of user II. R EQUIREMENTS T OWARDS MBUID A PPROACHES interfaces (UIs) and aims at reducing the amount of time consumed by the manual UI creation: about 48% of the source Requirements towards MBUID approaches can be catego- code and about 50% of the implementation time is spent on rized into core and additional requirements. Core requirements the UI development [9]. focus on the core functionalities of any MBUID approach, MBUID utilizes models on different levels of abstraction e.g., the possibility to design models for the UI creation. As for developing the UI, thus, it would benefit from an arbitrary all MBUID approaches deliver those, following, we focus on number of classification levels. As those models are inter- the additional requirements, which target advanced features dependent, changes in one model have to be synchronized enabling effective and efficient design of UIs. Following, the most relevant additional requirements, taking into account the Framework (CRF) [14]. This framework presents an overall goal of this paper, are presented. structure for MBUID approaches which is on the one hand R1 Foster Productivity: Considering all of the aspects that valid for the majority of existing approaches [14] and on the should be accounted for while building a UI model (e.g., other hand used as a foundation for new MBUID approaches widgets, colors or arrangement), building models is consid- [15]–[21]. ered difficult [11]. Especially if the modeling language only The CRF constitutes a four-layered framework for structur- provides primitive (generic) modeling concepts, the creation ing the development and the adaption of UIs [14]. The four of such rich models is a cumbersome endeavor as everything layers of the CRF are the Final UI (i.e., the actual UI imple- has to be recreated from stratch. Therefore, in order to mented in a programming language), the Concrete Interface support productivity of modeling, a modeling language should (i.e., a non-executable platform- and interactor-specific model provide semantically rich concepts which account for specific of the UI), the Abstract Interface (i.e., an abstract specification characteristics of user interfaces [7], [8]. of the UI) and Concepts and Task Models (i.e., the speci- R2 Foster Range of Reuse: Beyond this, MBUID ap- fication of relevant tasks and domain concepts). The layers proaches should be applicable in a wide range of different are based on three types of so-called ‘ontological models’ scenarios (economies of scale) [12]. Therefore, MBUID ap- [14]: domain-models “support the description of the concepts proaches should provide generic concepts which can be reused and user tasks” [14, p. 294], context-models “characterize the in different situations. However, this claim stays in opposition context of use in terms of user, platform and environment” to R1: In order to foster productivity, an approach requires [14, p. 294] and adaption-models “specify both the reaction semantically rich concepts. However, such specific concepts in case of change of context of use and a smoothly way for can presumably not be reused in a wide range of scenarios. commuting” [14, p. 294]. In contrast, in order to be reusable in different scenarios, an In order to transition from one layer to another, model approach has to provide generic concepts, which hampers the transformation is applied [16]. Model transformation is defined productivity. as the application of transformation rules in order to translate R3 Transparent Propagation of Modifications: Due to the a model into either text or another model (which adheres omnipresence of change, developed UIs have to be adapted to another metamodel) [22]. The translation from Concepts continuously to changed requirements during their lifecycle. and Task Models to Abstract Interface constitutes a model For this reason, it is necessary to modify the corresponding transformation, as both models have different intentions, thus, models in order to satisfy those changed requirements. Subse- they adhere to different metamodels. quently, those changes should be reflected in the corresponding In contrast, the transformation from the Abstract Interface source code. However, it should not be necessary to recompile to Concrete Interface is unsatisfactory. As an Abstract In- the source code, but the UI should be adapted during runtime. terface is interactor-independent and the Concrete Interface Therefore, it is desirable to have a transparent propagation of is interactor-dependent, several Concrete Interfaces can be change which applies the changes in the model in an automatic transformed or derived from one Abstract Interface [14]. manner to the source code and maintains the overall integrity Therefore, a number of Concrete Interfaces can be character- [8], [13]. ized or rather classified by one Abstract Interface. Thus, the R4 Extensibility of Language and Adaptability of Tool: Abstract Interface rather represents a kind of metamodel for In literature, the omnipresence of change is mostly discussed the corresponding Concrete Interfaces. Therefore, this relation in terms of its implications for the created user interface, can be regarded as a model transformation, because both e.g., [13]. However, literature mostly neglects changes which models have different metamodels. However, an instantiation- go beyond the language application and require to adapt the relation between Concrete Interface and Abstract Interface language specification. For example, it might be desirable to would be more appropriate because an Abstract Interface can add new concepts to the language specification by refining be considered as a class for a number of Concrete Interfaces. existing ones (e.g., a refined Button which adheres to a cor- The transformation from the Concrete Interface to the Final porate design). In that context, it should not only be possible UI is also a model transformation, as source code (i.e., text) is to enhance the language specification on demand with a new generated based on a model. However, the transformation itself concept, but also to adapt the corresponding tool. is not satisfying, as it is afflicted by well-known synchroniza- tion problems. If there are changes to the model, those changes III. S HORTCOMINGS OF THE TRADITIONAL PARADIGM have to be transferred to the source code and vice versa. We argue that MBUID approaches which rely on the The lack of an instantiation-relation and the necessity of traditional paradigm cannot entirely satisfy the additional code generation is not caused by a misconception of the CRF requirements due to the limitations imposed by the traditional itself. However, they are a consequence of the traditional conceptual modeling and corresponding tools implemented conceptual modeling in combination with the predominant using prevalent object-oriented programming languages. programming languages. In order to illustrate the implications of the prevalent The “prevalent programming languages are restricted to the paradigm on current MBUID approaches, it is discussed using dichotomy of objects and classes” [23, p. 32]. Therefore, there a prototypical MBUID approach named Cameleon Reference is only one classification level, i.e., an entity is either a class or a corresponding instance. This dichotomy in programming in the tool. Thus, the traditional paradigm does not allow languages influences the tool support. Software tools which enhancing an approach during runtime. support the development of MBUID models, implement the In consequence, the prevalent paradigm consisting of tra- required modeling concepts in a programming language. Thus, ditional conceptual modeling and predominant programming the modeling concepts are on the class-level. Therefore, the languages is not able to satisfy the identified requirements. created models are instances of the modeling concepts, i.e., in Therefore, in the next section, we investigate an alternative the realm of those software tools, the created MBUID models paradigm comprising a multi-level modeling and programming are on the object level [23]. However, those MBUID models approach. are models of the generated UI, thus, they are conceptually (at least) on the level of classes. As consequence, it is necessary IV. M ULTI - LEVEL M ODELING AND L ANGUAGE to generate corresponding classes from the instances in order E XECUTION E NGINE to allow a further instantiation. Nevertheless, the usage of In order to satisfy the identified requirements, an approach corresponding software tools implies a mismatch between the is required which supports multiple levels of classification as conceptual and the technical level of a MBUID model. Thus, well as a corresponding execution engine. Although different the current MBUID modeling tools cannot adequately support multi-level modeling approaches (e.g., [24], [25]) as well as the MBUID approaches due to the limitations imposed by the execution engines (e.g., [26], [27]) exist, to the best of our prevalent programming languages. knowledge there is no other pair of multi-level modeling ap- Due to these limitations, current MBUID approaches are proach and corresponding language execution engine besides not capable of propagating modifications transparently (R3). FMMLx (Flexible Meta-Modeling and Execution Language) During design time, the existing models are transformed into [1] and XModeler [28], [29] which allows modelling as well source code, which can be executed afterwards. If there are as executing behavior. Therefore, it becomes our approach of changes to the model, the corresponding source code is simply choice. recreated, i.e., these are changes on the class level. During FMMLx builds on XCore (the XModeler metamodel), thus, runtime, it is not possible to recreate the source code in it incorporates XCore’s recursive, self-reflexive architecture. that way, but it is necessary to adapt the existing objects. This architecture is inspired by Hofstadter’s praise of re- For this reason, the models are interpreted first, followed by cursion called “golden braid” [30]. In this architecture, the invoking adaption mechanisms on the objects. Such adaption instance-of-relation between class and object is enriched by mechanisms are hazardous, because an inappropriate adap- a specialization-relation. Thus, the concept class is a special- tion might lead to runtime failures. As traditional conceptual ization of the concept object. Therefore, a class can be in- modeling and predominant programming languages are not stantiated to another class, i.e., it enables a recursive language tightly integrated, it is necessary to implement complex trans- architecture. Hence, FMMLx allows for an arbitrary number of formation mechanisms in order to connect both. Therefore, the classification levels. Furthermore, as all classifications levels combination of traditional conceptual modeling and predom- are in the same model, there is no strict separation of language inant programming languages is not capable of propagating levels. It is of note that FMMLx also provides the concept modifications transparently. inheritance in addition to the instantiation. Furthermore, the application of traditional conceptual mod- Moreover, FMMLx contains the concept of intrinsicness eling implies a conflict between productivity (R1) and range which allows a deferred instantiation of attributes, operations of reuse (R2) as discussed in the previous section. Traditional and associations. Intrinsicness assigns an instantiation level conceptual modeling does only allow satisfying one demand to those entities [1], i.e., they are instantiated on the cor- while neglecting the other [23]: An approach can contain responding classification level. Therefore, the dichotomy be- semantically rich concepts (in the sense of domain specific tween instantiation and specialization is relaxed, as attributes, modeling languages), thus, foster the productivity. However, operations and associations can be instantiated as well as such concepts can presumably not be applied in a wide range inherited from one classification level to the next lower level. of scenarios. In contrast, an approach can contain generic A similar concept is the potency of Deep Instantiation [31]. concepts (in the sense of general purpose modeling languages), which can be reused in several scenarios. However, the con- cepts do not provide semantic richness, thus, the productivity gained by its usage is rather low. Hence, the traditional paradigm is only capable of satisfying either R1 or R2 at a time. Fig. 1. Notation FMMLx Beyond this, the traditional paradigm limits the extensibility of MBUID approaches (R4). It enforces a strict separation The notation of FMMLx is similar to the notation of UML of language specification and language application. Hence, class diagrams (cf. Figure 1). Beyond this, the classification adding further language concepts requires modifying the lan- level is indicated by the background-color of the name-box: guage specification, first, and adapting the corresponding tool M5 is visualized by a green background of the name-box, afterwards. After recompilation, the enhancements can be used M4 by red, M3 by blue, M2 by black and M1 by white (cf. Figure 1). Intrinsicness is presented as a black box with a white number (i.e., the instantiation level) in front of the feature’s name. XModeler (also known as XMF) is a language execution en- gine [1], [28], [29]. As explained, the XModeler’s metamodel is XCore, thus, XModeler allows for an arbitrary number of classification levels as well. XModeler does not only support the creation of models on several classification levels, but it also allows for model execution. Each entity of the system is not only a model but also source code. A modification of the model implies Fig. 2. Language Architecture a modification of the source code, and vice versa. Due to this shared representation, each entity can be executed. Thereby, execution is not limited to querying model elements, but each The language architecture presented in Figure 2, utilizes entity can be enhanced by algorithms for an execution in the the multi-level modeling in order to overcome this threat sense of a complete programming language [28], [29]. For this of redundancy. The concept Controller is divided into two reason, XModeler provides XOCL (eXecutable OCL) which concepts: the Model-bound Controller and the Controller. is an enhanced version of OCL (Object Constraint Languages) While a Model-bound Controller implements the methods that comprises imperative features [28]. necessary to access a Model, a Controller is an instance of a The usage of FMMLx in combination with XModeler’s Model-bound Controller and implements the access methods capabilities for modeling and programming constitutes an for the View. Due to the instantiation relation between Model- integrated environment. The UI design and the UI execution bound Controller and Controller, the access methods for the is performed in the same system. Hence, there are no issues models can be implemented in the Model-bound Controller related to the synchronization of a design and an execution once and reused by each Controller. environment. Therefore, a UI can directly be executed without It is of note that the arrangement of the language archi- further effort after designing or modifying it. tecture should not be mistaken for a dedicated assignment to Furthermore, the integrated environment can also serve as a classification levels, e.g., the position of the concept Controller live-editor. This means, that such a multi-level approach is not in Figure 2 does not necessarily assign it to M1. On the con- limited to modifying a model and executing it afterwards, but trary, our current research indicates that the concept Controller it is capable of modifying a model and adapting corresponding should also be differentiated over several classification levels. UIs during runtime automatically. Those capabilities enable a However, for the purpose of this paper, a small subset of the tight interweaving of the development and the test of a UI. domain of discourse is selected, which allows to satisfy the identified requirements. Therefore, the implemented language V. A P ROTOTYPICAL M ULTI - LEVEL MBUID A PPROACH architecture comprises only three classification levels: M2 , M1 Following, a prototype is presented which constitutes a and M0 . The levels M2 and M1 are for designing a UI for rudimentary multi-level MBUID approach. As already dis- an existing model; the level M0 represents the execution of cussed, the selected multi-level paradigm is the configuration the designed UI. That is, the elements of the running UI are of FMMLx and XModeler. This prototype implements selected actual instances of the Controller respectively of the View. aspects only in order to illustrate the capabilities of a multi- Following, the specified language concepts for the View and level approach for MBUID. Therefore, this approach neglects for the Controller are presented. features of prevalent approaches (e.g., the consideration of task The View is based on the language concepts presented in models or an explicit visual notation). However, this approach Figure 3. These concepts provide a basis for developing a is intended to illustrate a potential solution for the discussed library of all supported VisualizationElements. Furthermore, requirements. Figure 3 contains selected instantiations, i.e., elements of As the application of FMMLx and XModeler constitutes such a library. VisualizationElements are differentiated in an integrated environment, it is not sufficient to focus only Widgets and VisualizationFeatures. Widgets constitute those on the UI design, but it is necessary to consider also the elements which are for interaction (e.g. Buttons, Radiobuttons execution. Therefore, an adequate language architecture has or Checkboxes). In contrast, VisualizationFeatures serve to been developed which supports both (Figure 2). characterize the Widgets (e.g., the widget’s background-color The language architecture is inspired by the MVC-Pattern or foreground-color). [32]. In this pattern, a Controller is in charge of synchronizing The selected instantiations of the language concepts contain a Model with a View. Consequently, if there are two Views for an abstract conception of the FormularWidget, which is the one Model, there are also two Controllers. As those controllers supertype for all form-widgets. As an exemplary special- relate to the same model, there is a high chance, that both ization, the already mentioned Widgets Button, Radiobutton controllers access the same aspect, thus, there is presumably and Checkbox are presented. For each FormularWidget, both redundant source code. the foreground-color and the background-color have to be Fig. 3. Language Concepts for the View and Selected Instantiations specified. Thus, FormularWidget has two associations to the with a Widget (WidgetRelation) or a VisualizationFeature (Fea- feature Color. tureRelation). The WidgetRelation contains a reference to a The language concepts which are specified for imple- Widget as well as a number of Configurations. A Configuration menting the Model-bound Controller, the Controller and the refer to a number of VisualizationFeatures and is valid in a Controller-Instance are presented in Figure 4. As the model specific context, e.g., for a given device, a given role or a given is mainly intended to illustrate the associations between the user. Thus, it is possible to customize the appearance of a View concepts, most of the attributes are faded out. The included to a specific device, a group of persons (i.e., to roles) or even language concepts refer to elements which support the de- to a specific user. Furthermore, it is also possible to connect a velopment of both the View and the Model. Elements of the Controller to a VisualizationFeature, i.e., it is possible to adapt View (cf. Figure 3) are marked with a green box with ‘VM’. a VisualizationFeature – and therefore, a View – according to The Model is created with FMMLx , thus, those concepts are information stored in the Model. part of XCore. Hence, those elements are marked by a yellow Moreover, each Controller might be the root-element of box with ‘XCore’. It is of note that this model does only a Screen and may have EventHandlers. Screens logically contain classes which are required for instantiating Model- bundle Controllers which View’s constitute one UI. Therefore, bound Controllers, Controller as well as Controller-Instances; Screen refers to one root-element which might contain further exemplary instances are presented in Figure 5 2 and 3 . controllers. Thus, the elements of one UI are ordered hierar- The superclass for controllers is the ElementXWidget which chically. describes that there is a Controller which connects a Model- EventHandlers are in charge of dealing with events triggered element with a View-element. The ElementXWidget is special- by the Model or a View. Therefore, handlers allow for detecting ized into AttributeXWidget and MetaclassXWidget. Those con- user interactions and serve to notify the controller about cepts describe the specific relation of an attribute respectively changes in the Model or the View respectively. Furthermore, a metaclass to any kind of Widget. AttributeXWidget and Meta- some events might require displaying another View. For exam- classXWidget are connected via three relations: hasAttribute- ple, after sending a search query, a View has to be displayed Type on M2 , displayAttributeType on M1 and displayAttribute which presents the results. Therefore, an EventHandler might on M0 . Those three relations are necessary concepts as they de- be connected to a Screen via a FollowingScreenRelation. A scribe different circumstances: hasAttributeType comprises all corresponding Screen is displayed if the guard-condition (i.e., attributes possessed by a class; displayAttributeType describes a XOCL-Expression) is satisfied. those attributes which are part of a UI, displayAttribute relates The defined Controllers and View-elements on M1 can to those attributes which are actually shown by a running UI, be executed by instantiating those elements to M0 . Thus, a i.e., it relate to potential customization. running UI consists of corresponding instances. ElementXWidget features a relation ViewRelation on M1 for Figure 5 presents an application of the implemented proto- associating the View. Such a relation can either be associated type. It aims at illustrating the development of a form for Fig. 4. Multi-level MBUID Metamodel creating new customers. In this example, the Customer is level of abstraction are semantically rich, thus, they foster characterized by the attributes name, firstname and isVIP 1 . productivity. Hence, multi-level modeling enables developing For the UI creation, a corresponding Model-bound Controller MBUID approaches, which satisfy both R1 and R2, e.g., in is created, first 2 . Following, it is instantiated to a Controller the presented prototype the relaxation is visible in two concept and a corresponding View 3 . By a further instantiation, the hierarchies: First, the MVC-concept Controller is refined over UI is executed, i.e., the form is shown 4 . three abstraction levels (Model-bound Controller, Controller, Controller-Instance). Second, the abstract concept Widget is VI. E VALUATION instantiated into the Button, Radiobutton and Checkbox, which Following, it is elaborated, how FMMLx and XModeler in are instantiated into corresponding instances in a UI. general, and the presented prototype in particular, are able to satisfy the identified requirements for MBUID. R3 Transparent Propagation of Modifications: R1 Foster Productivity & R2 Foster Reuse: The FMMLx and XModeler maintain a shared conceptualization FMMLx allows for an arbitrary number of classifications of model and source code. Due to this conceptualization, levels, thus, concepts can be defined on a high level of changes in a model imply changes in the source code. Hence, abstraction and be refined on lower levels. Due to Intrinsicness there is no necessity to implement error-prone mechanisms for it is furthermore possible to specify knowledge regarding low model transformations. In terms of MBUID approach, changes levels of abstraction already on a high level of abstraction. in a model imply a direct adaption of the corresponding This hierarchy of concepts allow to relax the tension be- UI during runtime. Thus, FMMLx and XModeler allow to tween productivity and reuse [1]. Concepts on a high level transparently propagate changes during runtime. Looking at of abstraction are generic, thus, they can be reused in a the prototype, changes in the underlying Controller-Instances wide range of scenarios. Furthermore, concepts on a low and the View-Instances lead immediately to an adaption of Fig. 5. Screenshots of the UI-creation using the XModeler the UI. Furthermore, changes to the state of the Controller, [8] J. Vanderdonckt, “Model-driven engineering of user interfaces: the View or the Model-bound Controller influence also the Promises, successes, failures, and challenges,” Proceedings of ROCHI, vol. 8, 2008. resulting UI. [9] B. A. Myers and M. B. Rosson, “Survey on User Interface Program- R4 Extensibility of Language and Adaptability of Tool: ming,” in Proceedings of the SIGCHI Conference on Human Factors in By applying FMMLx and XModeler, the definition and the Computing Systems. ACM, 1992, pp. 195–202. [10] R. Gerbig, “Deep, Seamless, Multi-format, Multi-notation Definition and application of a MBUID approach are not strictly separated as Use of Domain-specific Languages,” Ph.D. dissertation, Verlag Dr. Hut, both are contained in one multi-level model. Thus, enhance- 2017. ments of the approach are directly usable due to the R3 Trans- [11] A. R. Puerta and P. Szkeley, “Model-based Interface Development,” in Conference Companion on Human Factors in Computing Systems. parent Propagation of Modifications. Thus, FMMLx and ACM, 1994, pp. 389–390. XModeler enable approaches which are extensible and provide [12] M. Abrams, C. Phanouriou, A. L. Batongbacal, S. M. Williams, and an adaptable tool (e.g., the presented prototype). J. E. Shuster, “UIML: An appliance-independent XML user interface language,” Computer Networks, vol. 31, no. 11, pp. 1695–1708, 1999. VII. C ONCLUSION [13] R. France and B. Rumpe, “Model-driven Development of Complex Soft- ware: A Research Roadmap,” in 2007 Future of Software Engineering. In this paper, we applied a multi-level paradigm to the IEEE Computer Society, 2007, pp. 37–54. MBUID-field with the aim to show its advantages for the [14] G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, L. Bouillon, and J. Vanderdonckt, “A Unifying Reference Framework for multi-target user creation of UIs. For this reason, requirements related to the interfaces,” Interacting with Computers, vol. 15, no. 3, pp. 289–308, Jun. development UIs were identified which support an effective 2003. and efficient model-based development process. Against those [15] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, and V. López- Jaquero, “USIXML: A language supporting multi-path development of requirements, the limitations of the traditional paradigm have user interfaces,” EHCI/DS-VIS, vol. 3425, pp. 200–220, 2004. been shown. In order to overcome these limitations, a multi- [16] F. Paterno, C. Santoro, and L. D. Spano, “MARIA: A universal, declara- level approach consisting of the multi-level modeling approach tive, multiple abstraction-level language for service-oriented applications in ubiquitous environments,” ACM Transactions on Computer-Human FMMLx and language execution engine XModeler has been Interaction (TOCHI), vol. 16, no. 4, p. 19, 2009. suggested. In that context, it is discussed, how such a multi- [17] P. Akiki, “Engineering Adaptive Model-Driven User Interfaces for level approach can satisfy the requirements for a model-based Enterprise Applications,” phd, The Open University, Sep. 2014. [18] I. Marin, F. Ortin, G. Pedrosa, and J. Rodriguez, “Generating native UI development. As a proof of concept, a rudimentary proto- user interfaces for multiple devices by means of model transformation,” type has been designed and implemented, which illustrates Frontiers of Information Technology & Electronic Engineering, vol. 16, the potential of multi-level modeling and a corresponding no. 12, pp. 995–1017, Dec. 2015. [19] C. Wiehr, N. Aquino, K. Breiner, M. Seissler, and G. Meixner, “Im- language execution engine for MBUID. proving the Flexibility of Model Transformations in the Model-Based As the developed approach presents only a rudimentary Development of Interactive Systems,” UsiXML, p. 46, 2011. prototype, future work targets the development of a com- [20] B. Collignon, J. Vanderdonckt, and G. Calvary, “Model-Driven Engi- neering of Multi-target Plastic User Interfaces,” in Fourth International prehensive multi-level MBUID approach. For this purpose, it Conference on Autonomic and Autonomous Systems (ICAS’08), Mar. is not sufficient to transfer features of existing MBUID ap- 2008, pp. 7–14. proaches to a multi-level MBUID approach, but it is necessary [21] M. Blumendorf, S. Feuerstack, and S. Albayrak, “Multimodal User In- terfaces for Smart Environments: The Multi-access Service Platform,” in to identify potential for improvement concerning prevalent Proceedings of the Working Conference on Advanced Visual Interfaces. approaches. Furthermore, it would also be desirable, to not ACM, 2008, pp. 478–479. restrict the UI creation to a primary manual task, but to support [22] K. Czarnecki and S. Helsen, “Feature-based survey of model transfor- mation approaches,” IBM Systems Journal, vol. 45, no. 3, pp. 621–645, an automatic generation of UIs. Moreover, it would also be 2006. promising to incorporate further interaction technologies in [23] U. Frank, “Enterprise modelling: The next steps,” Enterprise Modelling order to incorporate further senses in the human-computer- and Information Systems Architectures, vol. 9, no. 1, pp. 22–37, 2015. [24] C. Atkinson, M. Gutheil, and B. Kennel, “A Flexible Infrastructure interaction. Those investigations constitute our future work. for Multilevel Language Engineering,” IEEE Transactions on Software Engineering, vol. 35, no. 6, pp. 742–755, Nov. 2009. R EFERENCES [25] B. Neumayr, K. Grün, and M. Schrefl, “Multi-level Domain Modeling [1] U. Frank, “Multilevel Modeling,” Business & Information Systems with M-objects and M-relationships,” in Proceedings of the Sixth Asia- Engineering, vol. 6, no. 6, pp. 319–337, Nov. 2014. Pacific Conference on Conceptual Modeling - Volume 96, 2009, pp. [2] T. Clark, C. Gonzalez-Perez, and B. Henderson-Sellers, “A foundation 107–116. for multi-level modelling.” in MULTI@ MoDELS. Tilburg University, [26] J. De Lara and E. Guerra, “Deep meta-modelling with metadepth,” Sep. 2014, pp. 43–52. in International Conference on Modelling Techniques and Tools for [3] C. Atkinson and T. Kühne, “In defence of deep modelling,” Information Computer Performance Evaluation. Springer, 2010, pp. 1–20. and Software Technology, vol. 64, pp. 36–51, Aug. 2015. [27] C. Atkinson and R. Gerbig, “Flexible Deep Modeling with Melanee,” [4] V. A. Carvalho and J. P. A. Almeida, “Toward a well-founded theory in Modellierung (Workshops), vol. 255, 2016, pp. 117–122. for multi-level conceptual modeling,” Software & Systems Modeling, pp. [28] T. Clark, P. Sammut, and J. Willans, Applied Metamodelling A Foun- 1–27, 2016. dation For Language Driven Development: Second Edition. Ceteva, [5] U. Frank, “Designing Models and Systems to Support IT Management: 2008. A Case for Multilevel Modeling.” in MULTI@ MoDELS, 2016, pp. 3– [29] ——, Superlanguages: Developing Languages and Applications with 24. XMF. Ceteva, 2008. [6] S. Al-Hilank, M. Jung, D. Kips, D. Husemann, and M. Philippsen, [30] D. H. Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid. New “Using multi level-modeling techniques for managing mapping infor- York: Basic Books, 1979. mation.” in MULTI@ MoDELS, 2014, pp. 103–112. [31] C. Atkinson and T. Kühne, “Reducing accidental complexity in domain [7] G. Meixner, F. Paternò, and J. Vanderdonckt, “Past, Present, and Future models,” Software & Systems Modeling, vol. 7, no. 3, pp. 345–359, 2008. of Model-Based User Interface Development,” i-com, vol. 10, no. 3, pp. [32] T. M. H. Reenskaug, “The original MVC reports,” Dept. of Informatics, 2–11, Nov. 2011. University of Oslo, Oslo, Tech. Rep., 1979.