Semantics of Modeling Languages

Summary of Most Relevant Topic Papers

To deal with model analysis, synthesis, evolution, definition of views, and abstraction based on models, we need a sound semantic foundation of the meaning of the models.

We also need a proper semantics when applying a given language to new domains, such as monitoring energy consumption or modeling flight safety rules for the European air traffic. We do this regularly with our language workbench MontiCore [KRV10], [HKR21].

The Meaning of Semantics and its Principles

Over the years we have developed a clear understanding of what the semantics of a model and a modeling language is. For example in [HR04] we discussed different forms of semantics and what they can be used for. We, in particular, distinguish between “meaning” that can be attached to any kind of modeling language and an often used narrow interpretation, that uses “semantic” synonymously to behavior of a program.

Each modeling language, whether it be UML or a DSL deserves a semantics, even if the language itself is for modeling structure, such as Class Diagrams or Architecture Description Languages. Furthermore, modeling languages are not necessarily executable and as their main purpose is abstraction from implementation details, they are usually not fully determined, but exhibit forms of underspecification. We discuss a very general framework for semantics definition in [HR04]. At the core, we use a denotational semantics, which is basically a mapping M from source language L (syntax) into a target language respectively a target domain S (semantic domain). In the following figure we see a combination of functions, where the first simplifies the syntax language by mapping redundant concepts to their simplest form (less concepts used, but usually more complex models).

While many attempts of defining semantics only give examples on how mapping M looks like, we advocate an explicit and precise definition of M to be able to analyze or compare the semantics of models. For example, refinement and evolution of models rely on such explicit denotational semantics.

System Model as Semantic Domain

To define a semantic domain we use a mathematical theory, that allows us to explicitly specify the desired properties of the target system, we are aiming at. We call the developed theory System Model. Its first version is explicitly defined in [RKB95] and [BHP+98] (including work from [GKR96], [KRB96] and [RK96]).

The System Model for the full UML, however, became a rather large mathematical theory, that captures object-oriented communication (method calls, dynamic lookup, inheritance, object identity) as well as distributed systems at various levels as states and state machines. We therefore developed the full system model for the UML in [BCGR09a] and discuss the rationale for it in [BCGR09]. See also [BCR07a] and [BCR07b] for more detailed versions and [CGR08] for an application on class diagrams. The following figure shows the structure of the semantic domain as a model hierarchy within the mathematical model.

The System Model for the full UML however became a rather large mathematical theory, that captures object-oriented communication (method calls, dynamic lookup, inheritance, object identity) as well as distributed systems at various levels as states and state-machines. We therefore developed the full system model for the UML in [BCGR09a] and discuss the rationale for it in [BCGR09]. See also [BCR07a] and [BCR07b] for more detailed versions and [CGR08] for an application on class diagrams.

The system model and its variants are used for a variety of tool embeddings of the semantic domain. We provide a structured approach for system model-based modeling language semantics definitions in [GRR09]. [MRR10] explains the case for semantic model differencing as opposed to syntactic comparison. In [MRR11d] (based on [MRR11a]) we encoded a part of the semantics, big enough to handle differences of activity diagrams based on their semantics. In [MRR11f] we compare class and object diagrams based on their semantics and in [BKRW17] we look at the semantic differences between variants of component and connector architectures similar to SysML’ BDDs.

In [BR07] we have defined a much simpler mathematical model for distributed systems based on black-box behaviors of components, hierarchical decomposition, but also the sound mathematical theory of streams for refinement and composition. While this semantic model is useful for distributed real-time systems, such as Cloud, Internet of Things or CPS, it does not exhibit concepts of objects and classes.

We also discussed a meta-modeling approach [EFLR99]. As nothing is as mighty and comfortable as mathematical theories, one needs to carefully design the semantics in particular if a concept of the language does not have a direct representation in the semantics domain. Using a metamodel to describe the semantics is appealing, because the syntactic domain L is meta-modeled anyway, but also demanding, because both the semantic domain S and the mapping M need to be encoded using meta-modeling instead of mathematical concepts. We learned, that meta-modeling is limited, e.g., in its expressiveness as well as due to finiteness.

Semantics of UML and Object-Orientation

In the early days, when modeling technology was still in its infancy, it was of interest to precisely understand objects, classes, inheritance, their interactions and also how modeling technologies, like the upcoming UML, describe those. [BGH+97] discusses potential modeling languages for the description of an exemplary object interaction, today called Sequence Diagram, and a complete description of object interactions, which obviously needs additional mechanisms, e.g., a sequential, parallel or iterative composition of Sequence Diagrams.

Furthermore, [BGH+98b] discusses the relationships between system, a view and a complete model in the context of the UML. And [BGH+98a] describes mechanisms to specify exemplary and complete object interactions, giving e.g. Sequence Diagrams a more powerful semantics.

Abstraction, Underspecification and Executability

A modeling language is only a good language, if it allows to abstract from implementation details. Abstraction however often means that its models are not fully determining the original, but exhibit underspecification. Underspecification is regarded as freedom of the developer or even of the implementation to choose the best solution with respect to the given constraining specification. It is an intrinsic property of a good modeling language to allow underspecification.

As a consequence a semantic mapping of an (underspecified) model into a single running program cannot be correct or useful in order to capture the semantics adequate. To tackle underspecification, we use a set-based mapping. This means a single model is mapped to a set of possible implementations all of which fulfill the constraints given by the model. This approach has several advantages:

  1. Each element in the semantics can be an executable implementation, we just do not know which of them will be the final implementation.
  2. Given two models, the semantics of composition is defined as intersection: these are exactly the systems that implement both models. This approach is based on “loose semantics”, where an implementation is allowed to do everything that has not explicitly been forbidden by the specification.
  3. A model is consistent exactly when it has a nonempty semantics.
  4. Refinement of a model on the syntactic level maps to set inclusion on the semantics.

Using sets of executable systems in the semantic mapping combines the denotational approach with an operational approach that is perfectly suited for semantics for modeling languages.

Semantic Variation Points

In the standardization of the UML the contributors had some challenges to agree on the meaning of quite a few modeling concepts. To some extent this is due to political reasons (tool vendors try to push their already implemented solution), but to a large extent this is also due to the attempt of the UML to describe phenomena in various real world and application domains as well as software/technical domains. As it is a bad idea to capture different phenomena with the same syntactical concept, the UML standard introduces the semantic variation point without describing precisely what it means and how to describe it.

In [GR11], [CGR09] we have discussed the general requirements for a framework to describe semantic and syntactic variations of a modeling language. We also introduced a mechanism to describe variations (1) of the syntax, (2) of the semantic domain, and (3) of the semantic mapping using feature trees for class diagrams and for object diagrams in [MRR11f] as well as activity diagrams in [GRR10]. Feature trees are a perfect concept to capture variation points and denotational semantics based on a system model allowing to explicitly describe the effect of the variant.

In [Rum17] (or its German version [Rum12]) we have embodied the semantics in a variety of code and test case generation, refactoring and evolution techniques to make UML semantics amenable to developers without exposing the formalism behind. Additionally, [LRSS10] discusses evolution and related issues in greater detail.

Streams and Automata as Semantic Foundation

It is also noteworthy that we have used the mathematical concept of streams (e.g., [BS01] [RR11] also discussed in [RW18]) and various extensions including automata [Rum96] as semantic basis for the kind of systems, we have in focus: distributed, asynchronously communicating agents, which can be regarded as active objects. We illustrate our state machine formalism and its stream-based composition in with State-Based Modeling (Automata).

A realization of the untimed version of these theories in the Isabelle verification tool is defined in [BKR+20].

Key Statements

  1. Semantics of modeling languages helps to understand, analyze and manipulate its models.
  2. Semantics is precisely defined only using mathematics theories.
  3. The system model is a semantic theory based on streams and automata to describe distributed components.
  4. Semantic variation points can be captured precisely this way.
  5. Refinement, composition and evolution, e.g. through differencing can be defined using semantics.
  6. Encoding of semantics in formal tools helps to execute analyzes, consistency checks etc.

Selected Topic-Specific Publications

  1. [HKR21]
    K. Hölldobler, O. Kautz, B. Rumpe:
    MontiCore Language Workbench and Library Handbook: Edition 2021.
    Aachener Informatik-Berichte, Software Engineering, Band 48, ISBN 978-3-8440-8010-0, Shaker Verlag, May 2021.
  2. [BKR+20]
    J. C. Bürger, H. Kausch, D. Raco, J. O. Ringert, B. Rumpe, S. Stüber, M. Wiartalla:
    Towards an Isabelle Theory for distributed, interactive systems - the untimed case.
    Aachener Informatik Berichte, Software Engineering, Band 45, Shaker Verlag, Mar. 2020.
  3. [RW18]
    B. Rumpe, A. Wortmann:
    Abstraction and Refinement in Hierarchically Decomposable and Underspecified CPS-Architectures.
    In: Principles of Modeling: Essays Dedicated to Edward A. Lee on the Occasion of His 60th Birthday, Lohstroh, Marten and Derler, Patricia Sirjani, Marjan (Eds.), pp. 383-406, LNCS 10760, ISBN 978-3-319-95246-8, Springer, 2018.
  4. [Rum17]
    B. Rumpe:
    Agile Modeling with UML: Code Generation, Testing, Refactoring.
    Springer International, May 2017.
  5. [BKRW17]
    A. Butting, O. Kautz, B. Rumpe, A. Wortmann:
    Semantic Differencing for Message-Driven Component & Connector Architectures.
    In: International Conference on Software Architecture (ICSA’17), pp. 145-154, IEEE, Apr. 2017.
  7. [MRR11a]
    S. Maoz, J. O. Ringert, B. Rumpe:
    An Operational Semantics for Activity Diagrams using SMV.
    RWTH Aachen University, AIB-2011-07, Technical Report, Aachen, Germany, Jul. 2011.
  8. [GR11]
    H. Grönniger, B. Rumpe:
    Modeling Language Variability.
    In: Workshop on Modeling, Development and Verification of Adaptive Systems, pp. 17-32, LNCS 6662, Springer, 2011.
  9. [MRR11f]
    S. Maoz, J. O. Ringert, B. Rumpe:
    Semantically Configurable Consistency Analysis for Class and Object Diagrams.
    In: Conference on Model Driven Engineering Languages and Systems (MODELS’11), pp. 153-167, LNCS 6981, Springer, 2011.
  10. [RR11]
    J. O. Ringert, B. Rumpe:
    A Little Synopsis on Streams, Stream Processing Functions, and State-Based Stream Processing.
    In: International Journal of Software and Informatics, 2011.
  11. [MRR11d]
    S. Maoz, J. O. Ringert, B. Rumpe:
    ADDiff: Semantic Differencing for Activity Diagrams.
    In: Conference on Foundations of Software Engineering (ESEC/FSE ’11), pp. 179-189, ACM, 2011.
  12. [KRV10]
    H. Krahn, B. Rumpe, S. Völkel:
    MontiCore: a Framework for Compositional Development of Domain Specific Languages.
    In: International Journal on Software Tools for Technology Transfer (STTT), Volume 12(5), pp. 353-372, Springer, Sep. 2010.
  13. [LRSS10]
    T. Levendovszky, B. Rumpe, B. Schätz, J. Sprinkle:
    Model Evolution and Management.
    In: Model-Based Engineering of Embedded Real-Time Systems Workshop (MBEERTS’10), pp. 241-270, LNCS 6100, Springer, 2010.
  14. [MRR10]
    S. Maoz, J. O. Ringert, B. Rumpe:
    A Manifesto for Semantic Model Differencing.
    In: Proceedings Int. Workshop on Models and Evolution (ME’10), pp. 194-203, LNCS 6627, Springer, 2010.
  15. [GRR10]
    H. Grönniger, D. Reiß, B. Rumpe:
    Towards a Semantics of Activity Diagrams with Semantic Variation Points.
    In: Conference on Model Driven Engineering Languages and Systems (MODELS’10), pp. 331-345, LNCS 6394, Springer, 2010.
  16. [BCGR09a]
    M. Broy, M. V. Cengarle, H. Grönniger, B. Rumpe:
    Definition of the UML System Model.
    In: UML 2 Semantics and Applications, K. Lano (Eds.), pp. 63-93, ISBN 978-0-470-52261-5, John Wiley & Sons, Nov. 2009.
  17. [BCGR09]
    M. Broy, M. V. Cengarle, H. Grönniger, B. Rumpe:
    Considerations and Rationale for a UML System Model.
    In: UML 2 Semantics and Applications, K. Lano (Eds.), pp. 43-61, ISBN 978-0-470-52261-5, John Wiley & Sons, Nov. 2009.
  18. [CGR09]
    M. V. Cengarle, H. Grönniger, B. Rumpe:
    Variability within Modeling Language Definitions.
    In: Conference on Model Driven Engineering Languages and Systems (MODELS’09), pp. 670-684, LNCS 5795, Springer, 2009.
  19. [GRR09]
    H. Grönniger, J. O. Ringert, B. Rumpe:
    System Model-based Definition of Modeling Language Semantics.
    In: Proc. of FMOODS/FORTE 2009, LNCS 5522, Lisbon, Portugal, 2009.
  20. [CGR08]
    M. V. Cengarle, H. Grönniger, B. Rumpe:
    System Model Semantics of Class Diagrams.
    TU Braunschweig, 2008-05, Informatik-Bericht, Germany, 2008.
  21. [BR07]
    M. Broy, B. Rumpe:
    Modulare hierarchische Modellierung als Grundlage der Software- und Systementwicklung.
    In: Informatik-Spektrum, Band 30(1), pp. 3-18, Springer Berlin, Feb. 2007.
  22. [BCR07b]
    M. Broy, M. V. Cengarle, B. Rumpe:
    Towards a System Model for UML. Part 3: The State Machine Model.
    TU Munich, TUM-I0711, Technical Report, Germany, Feb. 2007.
  23. [BCR07a]
    M. Broy, M. V. Cengarle, B. Rumpe:
    Towards a System Model for UML. Part 2: The Control Model.
    TU Munich, TUM-I0710, Technical Report, Germany, Feb. 2007.
  24. [HR04]
    D. Harel, B. Rumpe:
    Meaningful Modeling: What’s the Semantics of ”Semantics”?.
    In: IEEE Computer Journal, Volume 37(10), pp. 64-72, Oct. 2004.
  25. [BS01]
    M. Broy, K. Stølen:
    Specification and development of interactive systems: Focus on streams, interfaces, and Refinement.
    ISBN 1461300916, Springer Science & Business Media, New York, 2001.
  26. [EFLR99]
    A. Evans, R. France, K. Lano, B. Rumpe:
    Meta-Modelling Semantics of UML.
    In: Behavioral Specifications of Businesses and Systems, H. Kilov, B. Rumpe, I. Simmonds (Eds.), pp. 45-60, ISBN 978-1-4613-7383-4, Kluver Academic Publisher, 1999.
  27. [BGH+98a]
    R. Breu, R. Grosu, C. Hofmann, F. Huber, I. Krüger, B. Rumpe, M. Schmidt, W. Schwerin:
    Exemplary and Complete Object Interaction Descriptions.
    In: Journal Computer Standards & Interfaces, Volume 19(7), pp. 335-345, Elsevier Science Publishers B. V., Amsterdam, The Netherlands, Nov. 1998.
  28. [BHP+98]
    M. Broy, F. Huber, B. Paech, B. Rumpe, K. Spies:
    Software and System Modeling Based on a Unified Formal Semantics.
    In: Workshop on Requirements Targeting Software and Systems Engineering (RTSE’97), pp. 43-68, LNCS 1526, Springer, 1998.
  29. [BGH+98b]
    R. Breu, R. Grosu, F. Huber, B. Rumpe, W. Schwerin:
    Systems, Views and Models of UML.
    In: Proceedings of the Unified Modeling Language, Technical Aspects and Applications, pp. 93-109, Physica Verlag, Heidelberg, Germany, 1998.
  30. [BGH+97]
    R. Breu, R. Grosu, F. Huber, B. Rumpe, W. Schwerin:
    Towards a Precise Semantics for Object-Oriented Modeling Techniques.
    In: Object-Oriented Technology, ECOOP’97 Workshop Reader, J. Bosch, S. Mitchell (Eds.), LNCS 1357, Springer Verlag, 1997.
  31. [GKR96]
    R. Grosu, C. Klein, B. Rumpe:
    Enhancing the SysLab System Model with State.
    TU Munich, TUM-I9631, Technical Report, Germany, Jul. 1996.
  32. [Rum96]
    B. Rumpe:
    Formale Methodik des Entwurfs verteilter objektorientierter Systeme.
    ISBN 3-89675-149-2, Herbert Utz Verlag Wissenschaft, München, Deutschland, 1996.
  33. [RK96]
    B. Rumpe, C. Klein:
    Automata Describing Object Behavior.
    In: Object-Oriented Behavioral Specifications, B. Harvey, H. Kilov (Eds.), pp. 265-286, Kluwer Academic Publishers, 1996.
  34. [KRB96]
    C. Klein, B. Rumpe, M. Broy:
    A stream-based mathematical model for distributed information processing systems - SysLab system model.
    In: Workshop on Formal Methods for Open Object-based Distributed Systems, pp. 323-338, IFIP Advances in Information and Communication Technology, Chapmann & Hall, 1996.
  35. [RKB95]
    B. Rumpe, C. Klein, M. Broy:
    Ein strombasiertes mathematisches Modell verteilter informationsverarbeitender Systeme - Syslab-Systemmodell.
    TU München, TUM-I9510, Technischer Bericht, Deutschland, März. 1995.