Direkt zum Hauptbereich

Modeling Illusions

A very important tool in software engineering (SE) is modeling illusions. In SE, engineers most often focus solely on realizations not illusions. However, illusions are the magic to create self-contained worlds (or domains), to separate design spaces and thereby simplify design. Modeling illusions is an art which is rarely understood and applied.

What do I mean by illusions? Let me give you some examples: Look at your desktop on your computer screen -- it's an illusion. There is no desktop in your computer. See the little small icon you call a dustbin or trash can? It's an illusion. Take a screwdriver and open your computer; you won't find a dustbin in there. Your files on your hard disk are organized in directories which are nested in a hierarchy. It's an illusion. Your hard disk actually has multiple platters and read/write heads, and each platter is organized in tracks and sectors (see also "How Hard Disks Work"). You work with databases, handle tables, keys, relationships? The world implied by SQL is an illusion. Look at any serious, high-performance database implementation. It's about B-trees and similar stuff.

The essence is: You have to distinguish an illusion from it's realization. What they share and have in common is the (user) interface. It's the interface that creates an illusion!

You got it? What I'm after is the following:

Any interface creates an illusion. A software engineer should describe the illusion from two different viewpoints: One model describes the elements of the illusion, how they can be used, how they relate and interact and so on. It's a domain model of the illusion. The other model describes how the illusion was done; it unveals the trick of the "magician". It's a realization model of the illusion. Others might also call it an "implementation model".

My point is: Software Engineers usually miss the point to consider each model as a model in it's own right. They are sloppy with the domain model but careful with the realization model. This is bad, because domain models are one of the most valuable modeling techniques to reduce complexity for system's understanding. A domain model can be taken as serious as a realization model and being made executable. Then, you have a choice: You can look at your interface and work either with an executable model of the illusion or you can look at your interface and work with an executable model of the illusion's realization, thereby looking behind the scenes. The domain model lets us ignore the complexities of the realization; but the domain model is complete and creates a self-contained illusion. It is as if the magic were true. The realization model opens up a new level of complexity.

Let me give you a final example -- it also complements my criticism on "The law of leaky abstractions":

What kind of illusion does TCP create for you? The TCP user interface provides a connection-oriented communication service. It creates the illusion of a reliable connection to communicate data with someone else (you asked to accept the connection beforehand). That's the illusion.

If we look at how the trick is done, the realization, we see a state machine realizing a nice rendezvous with a remote state machine sending IP datagrams back and forth. These two state machine implement the so-called TCP protocol. TCP relies on IP.

If you do socket programming (that's using TCP connections, for the ones who do not know), the socket library of your favorite programming language offers you to work with the illusion of a TCP connection. Beyond that socket libraries fall short of the notion of a connection. Nobody really cares about a rock-solid domain model of TCP, they all do in Unix/Linux and Windows is creating realizations. In a rock-solid domain model a TCP connection would be associated with some statistic properties. You could ask the connection about some statistic properties: How reliable is the connection, how many data packages got lost and had to be retransmitted etc.? If a domain model of TCP were carefully done and accessible in socket libraries, nobody would be so naive to believe that TCP would come at no costs and actually be 100% reliable. If you abstract these details away, you might do so for the purpose of simplification, but you should know what you're doing.

Beliebte Posts aus diesem Blog

Lidl und der Kassen-Bug

Es gibt Fehler, im Informatiker-Jargon "Bugs", die etwas anrühriges haben. Ich bat den Menschen an der Kasse bei Lidl um einen Moment Geduld und meine Kinder um Ruhe, um nicht den wunderbaren Moment zu verpassen, bei dem es passierte. Der Lidl-Mensch fluchte kurz auf -- und ich war entzückt! "Einen Moment, davon muss ich ein Foto machen!" Und dann machte ich noch eines. Ich bin heute extra für diesen Fehler zu Lidl gepilgert -- ich wollte es mit eigenen Augen sehen. Gestern hat mir ein Student (vielen Dank Herr Breyer) von diesem Fehler in einer EMail berichtet. Ein richtig schöner Fehler, ein Klassiker geradezu. Ein Fehler, den man selten zu Gesicht bekommt, so einer mit Museumswert. Dafür wäre ich sogar noch weiter gereist als bis zum nächsten Lidl. Der Fehler tritt auf, wenn Sie an der Kasse Waren im Wert von 0 Euro (Null Euro) bezahlen. Dann streikt das System. Die kurze Einkaufsliste dazu: Geben Sie zwei Pfandflaschen zurück und Lidl steht mit 50 Cent bei Ihne...

Syntax und Semantik

Was ist Syntax, was ist Semantik? Diese zwei Begriffe beschäftigen mich immer wieder, siehe zum Beispiel auch " Uniform Syntax " (23. Feb. 2007). Beide Begriffe spielen eine entscheidende Rolle bei jeder Art von maschinell-verarbeitbarer Sprache. Vom Dritten im Bunde, der Pragmatik, will ich an dieser Stelle ganz absehen. Die Syntax bezieht sich auf die Form und die Struktur von Zeichen in einer Sprache, ohne auf die Bedeutung der verwendeten Zeichen in den Formen und Strukturen einzugehen. Syntaktisch korrekte Ausdrücke werden auch als "wohlgeformt" ( well-formed ) bezeichnet. Die Semantik befasst sich mit der Bedeutung syntaktisch korrekter Zeichenfolgen einer Sprache. Im Zusammenhang mit Programmiersprachen bedeutet Semantik die Beschreibung des Verhaltens, das mit einer Interpretation (Auslegung) eines syntaktisch korrekten Ausdrucks verbunden ist. [Die obigen Begriffserläuterungen sind angelehnt an das Buch von Kenneth Slonneger und Barry L. Kurtz: Formal Syn...

Factor @ Heilbronn University

It was an experiment -- and it went much better than I had imagined: I used Factor (a concatenative programming language) as the subject of study in a project week at Heilbronn University in a course called "Software Engineering of Complex Systems" (SECS). Maybe we are the first university in the world, where concatenative languages in general and Factor in specific are used and studied. Factor is the most mature concatenative programming language around. Its creator, Slava Pestov, and some few developers have done an excellent job. Why concatenative programming? Why Factor? Over the years I experimented with a lot of different languages and approaches. I ran experiments using Python, Scheme and also Prolog in my course. It turned out that I found myself mainly teaching how to program in Python, Scheme or Prolog (which still is something valuable for the students) instead of covering my main issue of concern: mastering complexity. In another approach I used XML as a tool ...