Direkt zum Hauptbereich

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.


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 ...