Download
The distribution includes a set of models that serve to illustrate the use of the tool. They are stored in the subfolder models. Most of the models are supplemented with videos that demonstrate their creation and use. The subfolder doc includes fundamental books on language engineering and selected publications on multi-level modeling.
Older versions can be found here.
Getting Started
- Guide: How to run the XModelerML
- Screencast: Installing XModeler on Windows
- Screencast: Installing XModeler on Linux
My first Multi-Level Model
The following example illustrates how to develop a multi-level model step by step. The model of a fleet management system integrates DSMLs with traditional object models and instantiations of these.
This video presents the step-by-step development of a small multi-level model. It also gives a introduction to basic features of the XModelerML.
Terminology
Multi-level modeling represents a new modeling paradigm. It is one characteristic of a new paradigm that traditonal concepts are not sufficient to adequately describe it. Therefore, multi-level modeling requires a specific terminology.
The term “classification” does not have exactly the same meaning as in traditional object-oriented approaches. This is the case for the associated term “level” as well, cf. (Kühne 2018). Therefore, we use the following terms (cf. Frank 2022). Through “concretization”, which we adopted from (Neumayr, Schrefl 2009), in contrast to “instantiation”, a “concretion”, in contrast to “instance”, of a class C on level m is created, which is a class on level m – 1. Concretization requires that at least one feature (attribute, as well as, in some cases, operation and association) of a class is instantiated in the concretized class. Other properties will usually be “inherited” (see “deferred instantiation” below). If all properties of a class are immediately instantiated, concretization is, at first, equivalent to instantiation. However, through adding further properties to the concretized class, it can be different from instantiation in that case, too. In the opposite direction, we speak of “intrinsic classification” in contrast to “classification” and “intrinsicly classified” in contrast to “classified”. Note, that the traditional terms are still needed for those cases where they apply: both instantiation and classification in a strict sense are possible in multi-level modeling, too. We refer to the tree of classes that are concretized from a class and its concretizations as a “concretization subtree”.
References
- Kühne, T.: A story of levels. In: R. Hebig, T. Berger (eds.) Proceedings of MODELS 2018Workshops, CEUR Workshop Proceedings, vol. 2245, pp. 673–682. CEURWS.org (2018)
- Neumayr, B., Schrefl, M.: Multi-Level Conceptual Modeling and OWL. In: C.A. Heuser, G. Pernul (eds.) Advances in Conceptual Modeling – Challenging Perspectives, Lecture Notes in Computer Science, pp. 189–199. Springer-Verlag Berlin Heidelberg, Berlin, Heidelberg (2009)
FMMLx
The Flexible Multi-Level Modeling and Execution Language is the foundational language of the XModelerML. It is a monotonic extension of XCore, the meta meta model of the original XModeler. It comprises the additional attributes to classes in XCore and two adaptor classes, MetaClass and MetaAdaptor, which serve the introduction of levels and specific instantiation methods.
The FMMLx features a graphical notation that can be replaced by more specific notations designed for particular DSML. The figure below gives an overwiew of language concepts and the corresponding notation.
- Frank, U. (2022). Multi-level modeling: cornerstones of a rationale. Software and Systems Modeling. Advance online publication. https://doi.org/10.1007/s10270-021-00955-1
- Frank, U. (2021). Prolegomena of a Multi-Level Modeling Method Illustrated with the FMMLx. In Proceedings of the 24th ACM/IEEE International Conference on Modell Driven Engineering Languages and Systems: Companion Proceedings. IEEE.
- Frank, U. (2018). The Flexible Modelling and Execution Language (FMMLx) — Version 2.0: Analysis of Requirements and Technical Terminology (ICB Research Report No. 66).
- Frank, U.; Clark, T.: Multi-Level Design of Process-Oriented Enterprise Information Systems. Essential Guidelines and two Case Studies based on the FMMLx and the XModelerML. In: Enterprise Modeling and Information Systems Architectures (EMISA). 2022
- Frank, U., & Töpel, D. (2020). Contingent Level Classes: Motivation, Conceptualization, Modeling Guidelines, and Implications for Model Management. In E. Guerra & L. Iovino (Chairs), MODELS ’20: ACM/IEEE 23rd International Conference on Model Driven Engineering Languages and Systems, Virtual Event Canada.
- Tony Clark, & Ulrich Frank (2018). Multi-Level Constraints. In Regina Hebig & Thorsten Berger (Eds.), CEUR Workshop Proceedings, Proceedings of MODELS 2018 Workshops co-located with ACM/IEEE 21st International Conference on Model Driven Engineering Languages and Systems (MODELS 2018), Copenhagen, Denmark, October, 14, 2018 (pp. 103–117). CEUR-WS.org. Retrieved from http://ceur-ws.org/Vol-2245/ocl\_paper\_2.pdf
Guidelines
Compared to traditional approaches to conceptual modeling, multi-level modeling offers additional abstraction. Using them properly requires specific design decisions that are not accounted for in traditional modeling methods. The following overview summarizes a first version of a multi-level modeling method (Frank 2022).
General Guidelines
Commonalities should be captured by an appropriate abstraction only, if the abstraction is likely to be invariant during the lifetime of a system. If part A of a system depends on part B, B should be more invariant than A. Every modification of a part has a possible impact on its dependants, which might require adapting them. Dependencies that may change over time should be relaxed.
Selection of Specific Design Guidelines
Design principle 1: Specify known knowledge on the highest
possible level within the scope of your project.
Design principle 2: The higher the level of a class, the more invariant it should be.
Design principle 3: The design of a class at any level should aim at modification consistency. In other words: concretization relationships between two classes on different levels should be invariant.
Design principle 4: Assign properties of classes on levels higher than 1 to categories.
Design principle 5: Avoid the introduction of “fake” levels, that is, of levels that could be expressed through generalization/specialization.
The process model model that structures the development of multi-level models consists of a general process model and supplementing micro processes for each phase
General Process Model
First Phase of the General Process Model
References- Frank, Ulrich: Prolegomena of a Multi-Level Modeling Method Illustrated with the FMMLx. In: MODELS ’21. Proceedings of the 24th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings. IEEE, 2021
- Lara, J. D.; Guerra, E.; Cuadrado, J.S.: “When and how to use multilevel modelling,” ACM Trans. Softw. Eng. Methodol.,vol. 24, no. 2, pp. 12:1–12:46, 2014. [Online]. Available: http://doi.acm.org/10.1145/2685615
Examples 1
For extending an Object Model with additional levels to get familiar with the new paradigm, it may be helpful to stepwise enhance an object model by enriching it with class at levels above 1. The video below shows how to design a simple DSML for modeling university course management systems. That requires classes on higher levels which enable user to define their own classes – by reusing and refining domain-specific concepts. The corresponding model (UniversityML) is available with the XModelerML distribution.
The next video shows a further extension of an UML object model. An object model that represents a simplified design of an invoicing application is extended by classes at higher levels. This higher level of abstraction promotes reuse and adaptability of the model and, hence, of the corresponding software system.
DSML for IT Management
IT management is responsible for planning, analysing and maintaining IT infrastructures. Since these infrastructures are often of remarkable complexity, models of IT infrastructures promise effective support. This video demonstrates the development of a small multi-level model of a simplified IT infrastructure that integrates language layers with models and instantiations of models.
References
- Frank, U. (2016). Designing Models and Systems to Support IT Management: A Case for Multilevel Modeling. In Proceedings of MULTI 2016 (pp. 3–24). Retrieved from http://www.wi-inf.uni-due.de/FGFrank/documents/Konferenzbeitraege/ML-ITML-Multi2016.pdf
- Frank, Ulrich; Kaczmarek-Heß, Monika; De Kinderen, Sybren: IT Infrastructure Modeling Language (ITML): A DSML for Supporting IT Management – ICB Research Report. 72. Essen 2022
Process Challenge
The MULTI challenges that started in 2017 provide an excellent opportunity to compare different approaches to multi-level modeling and to illustrate the potential of multi-level modeling over traditional approaches. Our contribution to the EMISA process challenge, which is an updated version of an earlier MULTI process challenge (Almeida et al. 2019) consists of two partially overlapping multi-level models, one addressing the software development domain, one the insurance domain. The challenge includes a description of the use cases and the corresponding requirements. The models that were created for the challenge are part of the XModelerML distribution.
This video provides a brief overview of the multi-level model of the software development process. It illustrates the relationships between different layers of the model and outlines how to adapt the models to more specific needs.
References- Frank, U.; Clark, T.: Multi-Level Design of Process-Oriented Enterprise Information Systems. Essential Guidelines and two Case Studies based on the FMMLx and the XModelerML. In: Enterprise Modeling and Information Systems Architectures, 2022
Advanced GUI Design
At first, the main focus of the XModelerML development was on language engineering and modeling – either with the diagram editor or with a model browser. However, for building applications, a GUI is indispensable. The implementation of a GUI builder from scratch would have required an effort beyond the available project resources. Therefore, we decided to reuse an existing tool and to integrate it widely transparently with the XModelerML. The video below demonstrates how to design a custom GUI within an external tool and integrate the result transparently with the XModelerML.
Examples 2
This series of screencasts serves two purposes. First, it provides a further explanation of the motivation for and rationale of multi-level language architectures. Second, it presents a use case, both from a build time and a runtime perspective to illustrate the benefits of multi-level modeling for developing and using software systems. In addition, the screencast includes a discussion of possible objections against multi-level language architectures as well as on outlook on future research.
Introduction
Focus on Build Time
Demo 1
Focus on Runtime
Demo 2
Possible Objections and Refutations
Associations Types
Definition and Use of Association Types
This screencast demonstrates how to define and use association types with the XModelerML. The current implementation is still in a preliminary mode. Therefore, making use of this new feature requires to set alphamode=true in the file user.properties that is part of the XModelerML distribution.