Model-Based Definitions

It is always relevant to have a precise and commonly shared understanding of the relevant concepts. Here come ours on modeling – compact, not many explanations, no examples. For those extra materials you may look at our publications.

Core Definition

For a detailed discussion of the possible implications of this definition, please consult our various publications. Highlights are, e.g., the discussion on semantics of models [HR04], the way how to construct modeling languages using the MontiCore language workbench [HKR21], and especially the discussion on underspecification as an intrinsic part of models as opposed to programs [RW18].

Classification of Model Kinds

Models can be classified in various ways, as shown below, even though not all classifications are equally relevant.

Which scope a model describes

• System model describes the overall system.
• Test model describes one or several tests and is used for testing.
• Component model describes a system component.
• Context model describes the context of a system or component under consideration. It is not to be confused with “context condition” introduced below. The context model is dependent on the scope of the development, i.e., which system components belong to the context. When the scope changes, e.g., to the next level sub-system, then system components and their models become context elements.

Which aspect of a system a model describes

• Behavior model, structure model, architecture model, interaction model, state model, communication model, data model, etc., are models that serve the purpose of describing a respective aspect of a system or component.

In which development activity/phase a model is defined and used

• Requirements model, functional model, logical model, technical model, and implementation model, but also architecture model, test model, etc. are models that are mainly developed and used in the respective activity of a development project.
• Note that many models are used for other purposes, e.g., scientific models or data models.

Form and representation of the model

• Conceptual model is a representation of entities and their relationships. This is a broadly applicable term for many kinds of models. It is prominent in the database and the ontology/logical communities and very much depends on the term “entity”.
• Physical model is a physical, touchable model (it hurts when it falls on your feet).
• Thought model (mental model) is the mental construction of a person to gain an understanding of the system of interest. It is argued that any explicit model is translated by the reading person into an internal thought model.
• Paper model (blackboard model) is an informal drawing denoted on paper, a wall, or a board.
• Explicit model is a model denoted in an explicit modeling language, such as UML, SysML, or a domain-specific language.
• Diagram is an explicit model denoted in a diagrammatic modeling language, such as UML’s class diagrams or Statecharts.
• Text model is an explicit model denoted in a textual modeling language, such as UML’s OCL or MontiCore’s CD4A.
• Programmed model is an implicit model that is encoded in an executable program. The model is hidden in the code and mainly usable for simulation. The programming language is not to be confused with the (nonexisting) modeling language.

How the model came into existence

• Designed model is a model that has been created through human activity.
• Learnt model is a model that has been constructed from data, e.g., using one of the various machine learning techniques.
• Derived model is a model that has been derived by some algorithm, e.g., through abstraction, composition, transformation, refinement, and other algorithmically assistable derivation techniques.

What the model is used for

A similar categorization that however addresses a mixture between usage and origin:

• Prescriptive model describes the system under development before the system actually is developed. This is typically a designed engineering model or it has been derived from designed models.

• Descriptive model describes a system that already exists. This is typically a designed scientific model, but also an engineering model, when the system has been realized. Descriptive engineering models allow to understand examine and optimize the already built system.

• Prescriptive model also describes a system that already exists, but it has its origin in observations on the system. It is learnt from these observations and related forms of data and has a rather implicit form, so that it cannot directly be examined, but executions, respectively queries produce answers, mainly to predict future behavior. Machine learning is based on statistic correlations and does not necessarily imply causality in such as form as covered by descriptive models.

What the model is applied on

• Engineering model (Development model) is a model that is used in a development project and denotes the system under development. This includes software, biological, mechanical, chemical systems as well as social, economic, or producing processes.
• Scientific model is a model that describes real-world phenomena and is used to understand the existing world and its processes.

“When the model doesn’t fit the modeled system, then the scientist says that the model is incorrect, while the engineer says the system was badly constructed.” (well known, true joke). We, however, observe models may serve both purposes because, e.g., biological science models may become bio-engineering models. In Computer Science, the situation is even more complicated because the existence of generators may change the purpose of a model from (scientific) understanding to constructive use and even to the implementation itself.

• Metamodel
  is a model describing some kind of meta-structure. A common use is to define the abstract syntax of a modeling language, which makes each model (or. to be exact: the model’s AST) an instance of the metamodel. The MOF provides a hierarchy of metamodels, where finally, the meta-meta-meta-model is an instance of itself.

In the domain of language engineering, we thus abandon fuzzy forms of uses and only use the more narrow definition:

Language

Programming languages, configuration languages, but also modeling languages are such languages that are understandable for both kinds of stakeholders, namely humans and computers.

UML and SysML are prominent modeling languages with relatively general applicability in various domains.

E.g., the MontiCore language workbench provides techniques to define domain-specific languages and offers a set of predefined domain-specific languages.

Parts of a language

A language is described by the following concepts:

• (1) Syntax (“representation” and “structure”)
• (2) Semantics (“meaning”)
• (3) Model library (“vocabulary”)
• (4) Pragmatics (“forms of use”)

The syntax of a language can be divided into the following aspects:

• (1.1) Concrete syntax
• (1.2) Abstract syntax (AST)
• (1.2) Context conditions (CoCos)

Syntax

The abstract syntax (AST) of a model is then a concrete value of the AST of the language.

The abstract syntax is usually defined using context-free grammars or class diagrams (also called “metamodels”). Both notations are limited in their expressiveness, and thus, it is usually necessary to add additional constraints to restrict the set of models to define the well-formed models:

Context conditions are thus also called well-formedness rules. Sometimes also, “static semantics” is used, but we regard this term as misleading because context conditions do not tell us anything about the meaning (i.e. semantics) but purely constrain the syntax.

Semantics

Special forms of semantics are (1) denotational semantics, (2) axiomatic semantics, and (3) operational semantics using different techniques and serving different purposes. We only look further at denotational semantics. It describes what a model means without talking about how this meaning is actually achieved. Denotational semantics is typically defined using mathematical constructs. As a result, it is quite abstract and typically requires some training in mathematics to understand. Its advantage is that because we have the full power of mathematics at hand, we do not have to suffer from computational limitations and can, e.g., adequately address the principle of underspecification.

Model Library

The existence of a library of reusable models is one key success factor for a language to become used in practice. Models only become reusable as independent, modular artifacts that can be somehow “imported”, “waved”, “merged”, or otherwise composed if appropriate operators exist. While modularity and, thus, extensive libraries are a standard in modern programming languages, many modeling languages suffer from inadequate or even missing composition operators and missing reusable libraries. Sometimes this is due to a lack of modularity in the modeling language itself.

Tools

Software tools can assist developers in all activities of all phases of a software life cycle, including management, quality assurance, requirements elicitation, design, implementation, integration, deployment, evolution, optimization, and automation activities. Software tools can also be used during the operation of the developed software program for its monitoring, debugging, repair, configuration, or other forms of analysis.

MontiCore, as described in [HKR21], is such a language workbench.

A language workbench can also be called a “meta-tool” as its focus are tools as products. A language workbench can also be used to recursively develop parts of itself.

Tools can be categorized according to the following options:

• An API-based tool is essentially a set of methods that can be called to execute the functionality within an already existing process. The set of methods is specific to the tool’s functionality.
• A command-line tool is an executable artifact that can be called from a command-line shell or a script and runs in its own virtual process space.
• A plugin is a special form of API-based tool, where the API is predefined by an integrated development environment (IDE), in which a tool is pluggable when it realizes that API. The tool’s API is IDE-dependent but rather independent of the tool’s functionality.

Accordingly, there are several kinds of sources used, and results tools can produce:

• The data may be available as an object structure within the program, which may be manipulated directly (API-based tools only).
• The data may be available as an artifact (file) in the directory and thus must be loaded or parsed into an internal representation.
• The data may be stored in a database and needs retrieval.

Although every set of methods might be regarded as an API and, therefore, as an API-based tool, we suggest that certain forms of coherent functionalities with adequate granularity should be called a tool. In practice, many tools come with both API and CLI interfaces because, typically, a main class method translates external invocation to internal API calls.

Development workflows, in general, may also involve developers, testers, or lead users, and there are some development processes where these workflows are made explicit. A tool workflow focuses only on the automation aspect, allowing the workflow to be executed fully automatically. This may happen upon each relevant software change (e.g., version commit), daily overnight, when certain stages, e.g., release, are reached, etc. Essentially a dual workflow can be defined using a purely sequential script, but various efficiency optimizations are very helpful:

• (1) the workflow should be executed incrementally, where only the necessary actions are repeated, and earlier intermediate results are reused,
• (2) the users don’t have to care about the action dependencies, but the workflow manager itself knows how to sequentialize the defined actions and also when actions can be executed in parallel.

Gradle and make are such workflow managers if configured well.

Model Engineering and its Activities

To better support the use of models during development, it will become necessary to further understand models in terms of how they can be transformed and analyzed, as well as understand the impact of software size and complexity on model creation, management, and evolution. We expect that “Model Engineering” will become a new and highly interesting sub-discipline in the Software Engineering discipline.

As a consequence: Model Engineering might be considered a new subdiscipline of Software Engineering.

The following definitions describe a number of operations on models.

Forms of Model Operations and Relations

While refactoring is typically regarded as “horizontal”, i.e., remaining on the level of abstraction, refinement is regarded as “vertical”, i.e., downstream from abstract requirements to concrete realization. Refactoring enables evolution.

Refinement is only possible if the modeling language itself provides forms of abstractions, which allow the omission of details, but also through explicit underspecification by using special language constructs.

Composition of models enables developers to decompose a problem and solve the resulting smaller problems separately, in parallel, and in a modular form. Even more, composition of models enables reusing predefined solutions, i.e. through reuse of models for example from a library.

It is noteable that composition may not only be applied to models. Related, but also to some extent orthogonal are component composition, tool composition, tool workflow composition, and language composition.

Development Activities

Code generation comprises all constructive activities, including the generation of tests, reports, documentation, and configurations, while model analysis comprises all analytic activities, including static analysis with formal methods on certain possible deficiencies, simulation of executable models for analyzing dynamic behavior in a relevant subset of scenarios, or testing. We distinguish high-level, complex analysis, e.g., with metric results from simple context conditions, which at this point have already been checked.

Model analysis deals with the questions of

• (1) whether the model itself is of high quality,
• (2) whether the model fits the modeled software, system, or real world, and
• (3) what analysis techniques must be provided for developers to enable them to retrieve useful information from the model.

Development Processes

Development activities are organized in development processes, which are classifiable according to the following definitions.

• In Model-based development (MBD), models are used in some activities of development, but the activities and their order basically remain the traditional development activities.
• In Model-driven development (MDD), models also drive and guide the development process, and thus, models are the primary engineering artifacts.

Model-driven development is much more helpful because the use of models must drive the process in such a way that other activities can be omitted or at least considerably reduced, such that the overall process becomes more efficient, more timely, and produces better results.

Further links

• Essays, Comments, Definitions around Modeling
• Publications
• Topic sorted list of most interesting publications
• Books
• Website of the SE