An Introduction to Modeling and Language Engineering – Part 1

About Models, Abstractions and Meta Models

As early as 1976, statistician George Box stated, “All models are wrong!”

The Playmobil horse was never a real horse, the LEGO® spaceship was not a real spaceship, and Super Mario and Lara Croft were not real either. But we had no problem with the fact that they were not real, because it was absolutely useful to play with them.

Let’s take the Millennium Falcon from the Star Wars universe as an example to explain a few things we deal with every day at itemis: Models, abstractions and meta models.

For those born before 1932 or after 2014, this is a picture of the Millennium Falcon.

It is obvious that a “real” Millennium Falcon is quite a complex system: hyperdrive, weapons, hiding places and so on. Spaceships are very large and very expensive to build.

So, to model a spaceship as a useful toy, we need to introduce abstractions. The abstractions define the specific aspects that the model encompasses. This reduces complexity and also makes the model affordable.

Here are a few examples of how to model the Millennium Falcon and what are the main features of the models:

1. A LEGO® model: consists of colored plastic pieces that can be mechanically attached to each other and represent the rough shape and color of the spaceship. It is much smaller than a real spaceship. It cannot fly.
2. A cast iron mode: made of metal like a real spaceship. No moving parts to play with. Does not fly.
3. A CAD computer model: digital model of the structure and geometry of each component of the spaceship and how they relate to each other. Still can’t fly.
4. A Star Wars computer game spaceship model: digital model, looks just like the original, it includes the behavior of the real Millennium Falcon: and yes, it can fly!

All of the above models are useful in different scenarios and for different types of users. There are hundreds of other models that serve different purposes and focus on different aspects of the Millennium Falcon’s physical structure, components or behavior. Think of photos, puzzles or life-size models that were used in the movie studios during the production of the Star Wars movies.

Take away points:

• Models are very useful representations of our reality: we use them all the time.
• Models reduce complexity by introducing abstractions.

Now that we have an idea of what models are, we can look at another important modeling aspect: Meta models.

Meta models define the elements that can be used in the modeling process and how they relate to each other. In the world of LEGO®, the meta model defines the type of building blocks and how they can be connected.

Meta models can also be thought of as the rules associated with creating the model. Strong meta models enforce strict rules and constraints when creating a model. Weaker meta models give more freedom and apply fewer constraints.

Creating a clay model of a spaceship offers maximum freedom and creativity in the modeling process. The shape, size and details of the ship can vary greatly. The clay does not restrict the modeling process. The clay meta model is weak.

A 500-piece puzzle of our Millennium Falcon, on the other hand, has the strongest possible meta model. There is only one way to use the puzzle correctly. There is no room for creativity. The puzzle’s meta model automatically helps you “get it right” because missing or misplaced pieces can be easily identified.

The LEGO® model lies between the clay model and the puzzle model in terms of the degree of freedom and the number of constraining rules. It allows the player to combine the available pieces very flexibly while enforcing some basic rules: e.g. bricks only fit together in a certain orientation.

Which is more fun to play with? That just depends on personal preference.

What makes work more fun? That depends on the task at hand.

If the model is small and simple enough to fully understand all dependencies and side effects, then a weak meta model with hardly any rules might be okay. Think of Microsoft Word® or PowerPoint® as “clay for system modeling” - with no real constraints on the author’s creativity.

In a more complex world with thousands of requirements, product variations, and many sometimes conflicting forces such as cost, performance, safety, you may want to give up some “creative freedom” in exchange for some support from the system to ensure model values are correct or complete.

Take away points

• Meta models define the underlying model elements and how they relate to each other. In a very real sense, you define the “language” you can use to express your models.
• The structures and rules enforced by the meta model can limit the user’s degrees of freedom, but in return help “get the model right”.

Model Transformations

Transformers® are both the most famous and the most popular robots ever. They have the ability to transform from a car or truck into a robot - and back again. That’s a very cool trick!

System models can also be transformed from one model to another. Depending on the underlying meta models, this transformation may or may not work equally well in either direction.

LEGO® models can again serve as an example. If a model consists of large, black bricks, it can easily be transformed into a model consisting of smaller, colorful bricks without losing previously modeled information such as the physical shape of the modeled object.

Transforming in the opposite direction may not work as well, since the larger bricks are limited in their ability to form smaller shapes, and black bricks cannot represent different colors.

Of course, at itemis we don’t usually play with LEGO®. We deal with models like UML, SysML, EMF, Franca or Autosar. Very often it makes sense to transform models. Every software language consists of specific notations, syntax and grammar (= meta model). The programs written in a software language are models. For this reason, model transformation can help us perform a very useful trick: It can help us generate software code from other models such as EMF or Franca. This is usually referred to as “code generation”.

Yes, and sometimes we actually play with LEGO®.

(itemis LEGO® model and instruction manual courtesy of Mathis Birken)

Part 2 of the introduction deals with additional concepts related to modeling. Following our familiar LEGO® models, we will look at languages, domain-specific languages (DSLs) and the work of itemis language engineers.

Model-Based Engineering at itemis — Language engineering, DSLs, and model-driven development: Model-Driven Software Development →