Descriptions and Models (1) – Four surprises

This blog series champions the application of essential model theoretic concepts to computers and computation and tries to show some surprising consequences.

It is one of the great achievements of model theory to present a concise approach how to distinguish between the description and the described and to define the precise relation between both as interpretation.  A description in a model theoretic sense consists of a finte sequence of characters from an alphabet. The interpretation maps the characters of the description onto the entities which are described: the model. Model theory thereby provides a precise definition of semantics: Meaning is attributed to descriptions by interpretation, which is to be performed by an interpreter. Models thereby exist only internally within some interpreter. In other words, the essence of model theory is that descriptions have no meaning per se, there is no meaning as such and meaning cannot be transported like energy or matter but meaning is awarded to descriptions by interpreters.

Simple as it sounds, this view provides at least 4 surprises for software developement.

1. “modelling” is synonymous with “describing”.
2. We can have both, different descriptions which are mapped by different interpretations onto identical entities, as well as identical descriptions which are mapped by different interpretations onto different entities.
3. A computer, described as processing a program description, has to be described as an interpreter in this sense, attributing meaning to descriptions.
4. To be of pragmatic value, models often need only to be “good enough”. So we have to face the fact that relevant requirements generally heavily underspecify our application design, leading to different implemented models even of identically specified applications. We thus have to learn to what extend it is necessary to share a common model for the different types of cooperations. 

The first two surprise will be dealt with in this blog, the next ones will be tackled in the following ones.

“modelling” is synonymous with “describing”

Let us assume, we have two different ways to describe program structures: From a model theoretic perspective both describe exactly the same entities, if both descriptions could be interpreted by the same interpreter, mapping both descriptions onto the same entities.  Just to give an example: We could use both, a programming language ProgLang and a graphical ‘modelling’ language GML do describe some class structures. If they describe the same entities, it would not matter, which description our interpreter would use to create its (internal) model. A good example would be the Specification and Description Language SDL of the CCITT

To us, graphical diagrams may be much better suited to present topological representable relations although they often represent only certain aspects. On the contrary, programs may not be as easily comprehensible, but usually claim to be complete. But both are descriptions of our application structure. If we say with GML “we model” and with ProgLang “we describe”, then we use the terms “to model” and “to describe” as logical synonyms, i.e. we can replace them by each other without changing the semantics of our sentence in a logical sense. The transformation between ProgLang and GML therefore is a translation.

If we do not distinguish clearly between descriptions and models, the chances are high, that we will soon talk about meta models and meta meta models, etc, without being capable of really expressing what we meant in the very beginning.

The necessity for formal semantics

The second surprise, directly motivates the necessity for formal semantics. Because the meaning of a description is the result of the interpretation function, we can be sure to have a well defined meaning only if the function of interpretation is well defined. This is the essence of formalizing semantics.

A textbook example of identical descriptions, carrying different semantics are sentences of colloquial language as well as graphical diagrams without formalized semantics. The high intuitiveness of graphical representations entails the substantial risk, that we interpret them as we interpret colloquial language, namely every reader applies a different interpreting function.

Take for example the famous ISO/OSI 7 layer model, which is supposed to represent software layers created by well defined interface. There are plenty of diagrams, which illustrate these levels quite demonstratively. However, have you ever asked yourself, why this “model” did never find widespread acceptance in application design? Instead, for example the TCP/IP stack realizes only 4 layers.  Wouldn’t it be a good explanation if the 7 ISO/OSI layers just do not represent good application architecture? For example, the usual relation between the  “application” part and the “presentation” part of a well structured application is just not a layered one in the ISO/OSI sense.

Now, why is it so important to express what we want a computer to do in a language with formalized semantics? Because the most relevant interpreter for our description is the computer and not the programmer. The computer does what the programmer describes with respect to its own interpretation, and not with respect to the programmer’s intention. In a nutshell, the computer does what the programmer describes but not what he means.