The three elements of a modelling language

Now that the reader is a fine connoisseur of the Empathy Canvas (Osterwalder et al., 2014, pp. 10–25), it is time to tell him our goal with this course: we would like him to be capable of inventing his own modelling languages and let people enjoy them via software applications.

The best way to acquire this know-how is to learn first to develop computer programs offering the possibility of manipulating already existing languages. This is what we plan to do, and our first app will be dedicated to the Empathy Canvas.

This short post defines the keywords the reader needs absolutely to understand and feel comfortable with because we will employ them all throughout the course. After reading it, you will know what a model, a language, a metalanguage, an abstract syntax, a concrete syntax, and a semantics are.

Abstract syntax, concrete syntax, and semantics

A modelling language is a set of rules followed by its users to represent and convey their ideas regarding a particular theme. The Empathy Canvas is, for instance, a modelling language whose theme is the understanding of what customers are looking for.

To create a modelling language, the first thing we must do is to list the concepts about which we want to talk through it, and the relations between these concepts it has to allow us to express. This list is called the abstract syntax (Brambilla et al., 2012, p. 57).

Below, we have reproduced the model we made in the previous post with the Empathy Canvas.

As a modelling language, the Empathy Canvas provides us with the concepts of goal, problem, and expectation. These concepts are connected as follows: customers have problems that prevent them from achieving their goals, but they will favour only solutions that meet their expectations. There are therefore, in the abstract syntax of the Empathy Canvas, at least three concepts and two relations: one relation between goals and problems (problems prevent customers from achieving their goals), and one relation between problems and expectations (customers have specific expectations that determine the solutions they consider acceptable for their problems).

Once we have decided on the abstract syntax of a modelling language, the next step is to design its concrete syntax (Brambilla et al., 2012, p. 57). This term refers to the notation the language brings to communicate the concepts of the abstract syntax and their relations.

For example, in Figure 1, we drew a circle, divided it into three areas, and wrote the goals, problems, and expectations of our readers respectively in the right, bottom, and top ones because the concrete syntax of the Empathy Canvas says to do so. However, we neither had to draw rectangles around them, nor did we have to add colours. Stylistic choices like ours in Figure 1 are said to be non-normative (Object Management Group, 2015) because they are not regulated by the concrete syntax.

The Empathy Canvas is a graphical modelling language which represents its concepts by combining drawings (the circle in the background) and text. Its concrete syntax is a graphical concrete syntax. Many languages are purely textual: they model things only with text structured in a special way. Their concrete syntaxes are textual concrete syntaxes.

A modelling language is not complete without a clear semantics (Brambilla et al., 2012, p. 57). This last ingredient clarifies the meaning of each concept and relation between concepts allowed by the abstract syntax. It makes everyone agree on the proper way to interpret and understand models created with the language.

For example, the semantics of the Empathy Canvas defines goals, problems, and expectations respectively as what customers want to make happen or see come true, hindrances that come their way, and the kinds of solutions they look for to overcome them.

Let us keep the same abstract syntax and the same concrete syntax but imagine an entirely different semantics. Let us say, for example, that goals, problems, and expectations are respectively situations customers absolutely want to avoid, bad habits they should break to ensure against them, and the kinds of solutions they look for to change. The model in Figure 1 then no longer makes sense, even if it fully respects the notation of the concrete syntax.

What is a modelling metalanguage?

A metalanguage is a language that serves to model the abstract syntax, concrete syntax, or semantics of other languages. In other words, a model produced with a metalanguage presents the abstract syntax, concrete syntax, or semantics of another language.

A metalanguage specialised in abstract syntaxes must be able to model its own abstract syntax. A metalanguage specialised in concrete syntaxes must be able to model its own concrete syntax. And a metalanguage specialised in semantics must be able to model its own semantics.

The most famous metalanguages are:

• the Essential Meta Object Facility (EMOF), standardised by (Object Management Group, 2016, pp. 25–34) to model abstract syntaxes;
• the Extended Backus-Naur Form (EBNF), standardised by (ISO/IEC, 1996) to model textual concrete syntaxes;
• and the Diagram Definition (DD), standardised by (Object Management Group, 2015) to model graphical concrete syntaxes.

For semantics, we often use a natural language, i.e. English, French, etc. The existence of dictionaries, which define, for instance, English words in English, proves that natural languages can describe their own semantics.

What is a model?

A model is a reduced representation of something. What we mean by saying this is that:

1. a model always has a subject: the thing modelled;
2. a model represents its subject: it allows to dispense with it;
3. a model reduces its subject: it focuses only on a relevant part of its properties (Brambilla et al., 2012, p. 2); it can be indefinitely refined by detailing what its makers set aside.

In software engineering, the production of a model is done respecting the abstract syntax, concrete syntax, and semantics of a modelling language.

Now, what is the point of modelling? What use are models?

Their role is to describe or prescribe (Brambilla et al., 2012, p. 2).

A descriptive model shows the subject as it is or was. The goal is to make the model conform to the subject. In painting, a portrait is a descriptive model.

A prescriptive model shows the subject as it must, should, or will be. The goal is to make the subject conform to the model. In civil engineering, plans drawn by an architect are prescriptive models that engineers must take into account to construct the building.

Please take the time to assimilate all the definitions we have just given. In the next posts, we will model respectively with EMOF and DD the abstract syntax and concrete syntax of the Empathy Canvas. We will then be ready to start coding.

Questions

Which approach do you prefer?

1. settle on an abstract syntax; next, design a concrete syntax; and, finally, explain the semantics;
2. settle on an abstract syntax; next, explain the semantics; and, finally, design a concrete syntax.

Bibliography

Photographic credits