Montag, Dezember 17, 2012

Softwarebau und Storytelling

Wenn Software-Entwickler über Software reden, dann übertragen sie die Welt der Klassen, Objekte, der Methoden in die Welt der Geschichten. Wir Menschen können nicht anders. Wir erzählen Geschichten, wenn wir uns erklären, was diese Klasse oder jenes Framework tut. Wir betreiben Storytelling, um uns die formale Welt eines Rechners erklärbar und beschreibbar zu machen. Wir müssen es in den Worten unserer Welt tun.

Das Problem? Die Welt eines Rechners ist eine formale Welt, ähnlich der Mathematik. Die Welt des Storytellings, des Geschichtenerzählens könnte nicht gegensätzlicher sein: Geschichten müssen nicht logisch sein, sie müssen nicht einmal stimmig sein, solange sie unsere Phantasie nicht überstrapazieren. Praktisch jedes Buch und jeder Film ist ein Beleg dafür, wie sehr wir bereit sind, uns auf selbst abstruse Geschichten einzulassen.

Und so versagen wir oft kläglich, unsere Stories zurück zu übertragen auf die strenge Welt eines Rechners. Die Inkonsistenzen unserer Vorstellungen straft die Software mit Fehlermeldungen ab. Das ist der Urgrund dessen, warum das Testing so notwendig und dringende Pflicht ist: Es geht um den Abgleich unserer Stories mit dem, was eine Software wirklich macht. Das hat erst einmal nichts mit Qualitätssicherung zu tun. Warum wir uns trotzdem so schwer mit dem Testen tun, ist psychologisch einfach erklärt: Wir sind auf einen Erhalt unserer Selbstbilder und Vorstellungswelten aus. Wir sind Wesen, die nur bedingt auf Empirie setzen, denen aber die Bewahrung der lieb gewordenen Meinungen, Ansichten und Stories so viel wert ist, dass wir sie ungern erschüttern lassen.

Das Drama des Software Engineering spitzt sich noch um einen weiteren Aspekt zu: Zwar arbeitet ein Rechner nach formalen Prinzipien, aber das Prinzip basiert letztlich auf einem sehr einfachen Gesetz: Dem Gesetz des nächsten Befehls! Die nächste Anweisung im Rechner wird kommen. Und sie wird tun, was sie tun muss. Ob darüber hinaus das Tun des Rechners sinnhaft, schlüssig und logisch ist, ist nicht im geringsten gewährleistet.

Und so prallen zwei Welten aufeinander -- die Welt des Rechners als formale, die Welt des Menschen mit seinem Storytelling als informale --, die eines eint: beide Welten erlauben das absolute Chaos. Rechner müssen außer dem Gesetz des nächsten Befehls keine Physik und keine Logik beachten, keine Plausibilitäten und keine Konsistenzen -- genauso wenig wie jede Story.

Daraus gibt es einiges zu lernen:

Erstens: Software Entwickler müssen es lernen, ihre informelle Ausdrucksformen in eine formale Form zu bringen -- und sie sollten diese Übertragungen stets auf Fehlannahmen etc. hin testen. Dafür gilt es psychologische Barrieren zu durchbrechen.

Zweitens: Da weder die Software noch die Story konsistent, plausibel und logisch sein muss, tun sich Menschen einen Gefallen, die formale Welt im Rechner auch zur Konstruktion formal-logischer Welten zu nutzen, die mehr einfordern, als nur das Gesetz des nächsten Befehls. Das kann zum Beispiel in Grenzen geschehen durch domänenspezifische Sprachen (DSLs), Kernel-Ansätze und ein konsequentes Schichtenmodell, durch den Einsatz logischer Sprachen wie Prolog etc. Oder, und das ist ein großes, sehr großes Korrektiv, die Software interagiert mit der physikalischen Welt (wie embedded Systems) und muss die dort vorzufinden Gesetze und Eigenschaften strengstens berücksichtigen.

Erst wenn das gegeben ist, bauen wir Software von der Qualität mit der auch Ingenieure ihre Werke erschaffen: Ingenieure werden von den Gesetzen der Natur optimiert. Das Gesetz des nächsten Befehls allein optimiert nichts. Und unsere Stories auch nicht.

Montag, Dezember 10, 2012

Brauchbare Klassendiagramme

Mich überrascht immer wieder, wie sehr Klassendiagramme in einer undefinierten Grauzone schweben zwischen Modellbeschreibung einer Problemdomäne und Dokumentation der Implementierung. Das ist nicht nur ein "Problem" von Studierenden, sondern auch von Profis.

Ein Klassendiagramm kann zwei Zwecken dienen, die sich an zwei Fragen festmachen lassen:

Dient das Klassendiagramm zur Erfassung einer gedanklichen, logischen Zerlegung einer fachlichen Problemdomäne (Modellierung)? Oder dient es zur Dokumentation der Klassenbezüge im Code einer Implementierungssprache (Realisierung).

Meist "hängt" ein Klassendiagramm genau zwischen diesen Welten und ist am Ende weder ein ausdrucksstarkes Modell (da es Ausdrucksmittel der UML ungenutzt lässt), noch eine korrekte Beschreibung der Realisierung, die in aller Regel das Klassendiagramm nicht einmal sauber umsetzt.

Um es konkreter zu machen:

Oftmals wird in Klassendiagrammen keine Mehrfachvererbung verwendet, obwohl sie bisweilen sehr elegante Zerlegungen und Wiederverwendungen von Modellanteilen erlaubt. Warum? Weil die Implementierungssprache (z.B. Java, C#) Mehrfachvererbung nicht kennt. -- Das sollte zwar kein Grund sein, sich in den Ausdrucksmöglichkeiten zurück zu halten, ist es aber faktisch immer wieder! Interessanterweise eben genau bei dem Thema "Mehrfachvererbung".

Andererseits sehe ich sehr oft, wie die Komposition und bisweilen auch die Aggregation in Klassendiagrammen verwendet wird. Dabei bietet keine mir geläufige OO-Sprache ein Sprachkonstrukt für die Komposition/Aggregation an -- vom Hörensagen ist eventuell Eiffel die große Ausnahme. Merkwürdigerweise scheint das Fehlen von Komposition und Aggregation in der Zielsprache den wenigsten Modellierer(inne)n Sorgen zu machen, ganz im Gegensatz zur Mehrfachvererbung. Dabei habe ich -- und das ist das Kuriose daran -- (fast) noch nie Implementierungscode gesehen, der die Komposition oder Aggregation korrekt umsetzt. Die wenigsten Programmierer(innen) wissen, wie Komposition in Code geht, und auch die gängigen Modellierungswerkzeuge versagen mit ihren Code-Generatoren an dieser Stelle oftmals kläglich.

Damit sind Klassendiagramme merkwürdige Artefakte: Sie sind oft halbherzige Modellbeschreibungen mit einem sehr implementierungszentrischen Blick. Und gleichzeitig versagen sie als Dokumentation des Programmcodes, der die vom Klassendiagramm geforderten Strukturbeziehungen nicht wirklich einlöst.

Darum halte ich es für sinnvoll, sauber und klar in zwei Klassendiagrammen zu denken, die den Unterschied zwischen fachlichem Modell und Implementierungsdokumentation offen legen und bewusst machen, statt ein Klassendiagramm mit unklarem Bezug und fraglichem Nutzen zu erstellen. Da viele IDEs wie z.B. Eclipe immerhin einfache Klassendiagramme aus der Implementierung abzuleiten vermögen, sollte der Fokus auf zwei Punkten liegen:

  1. Gute Klassendiagramme zu entwerfen, die die Problemdomäne versuchen ausdrucksstark zu modellieren -- ohne auf die Implementierungssprache zu schielen.
  2. Zu dokumentieren, wie das Klassendiagramm in die Zielsprache übertragen wird, so dass deutlich ist, wo Programmierdisziplin mit Blick auf das Modell eingefordert werden muss, und wo der Programmcode das Modell sauber umsetzt.


Donnerstag, Dezember 06, 2012

Denkspuren auf Google+ und Facebook

Seit wenigen Wochen gibt es mich auch unter Google+ und Facebook. Ich will verstehen lernen, wie sich die sozialen Medien anfühlen, ob sie für mich eine Bereicherung sind oder nicht, ob ich sie als wertschöpfend erlebe oder nicht. Tatsächlich hat mich der Vortrag von Lars Lehne motiviert, mich auf diese Welt einzulassen. Auch geht es mir darum mitzubekommen, was meine Studierenden mit diesen Welten verbinden.

Eines habe ich bislang festgestellt: Facebook scheint nichts für mich zu sein, ganz anders als für meine Studierenden. Vielleicht liegt es daran, dass ich nicht wirklich einen Bedarf habe, die Kontaktpflege mit "Freunden" über Facebook zu betreiben. Google+ hingegen spricht mich an. Das Format ist niederschwellig genug, so dass ich angefangen habe, öfter etwas zu posten. Und dass ich nicht gleich mit jedem Freund sein muss, sondern nur Kontakt-Kreise aufbaue, das scheint auch mehr zu mir zu passen.

Darum: Wenn Sie Lust haben, "besuchen" Sie mich auf Google+. Auf meiner Facebook-Seite passiert dagegen kaum etwas.