=Paper=
{{Paper
|id=Vol-2019/multi_2
|storemode=property
|title=A Multi-level Approach for Model-based User Interface Development
|pdfUrl=https://ceur-ws.org/Vol-2019/multi_2.pdf
|volume=Vol-2019
|authors=Björn Benner
|dblpUrl=https://dblp.org/rec/conf/models/Benner17
}}
==A Multi-level Approach for Model-based User Interface Development==
https://ceur-ws.org/Vol-2019/multi_2.pdf
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.