Modellierung

Wenn man sich einer Problemdomäne neu nähert hat man im wesentlichen die folgenden Aufgaben zu bewältigen:

1. Man muss die wesentlichen Begriffe der Problemdomäne finden.
2. Man muss verstehen, in welchem Verhältnis die gefundenen Begriffe zueinander stehen. Diese Struktur ist in der Regel weitaus wertvoller als die pure Auflistung der Begriffe.
3. In Problemdomänen, deren Komplexität aus der Vielfalt der Begriffe erwächst, findet man oft Taxonomien, die – mit hinreichender Vorsicht² – bei der Modellbildung zu beachten sind.
4. Auch wenn es etwas in Vergessenheit zu geraten scheint, wäre bei einem objekt-orientierten Herangehen auch festzulegen, welche Zuständigkeiten bei welchem Begriff liegen³.

Vielleicht etwas plakativer: Beispielsweise ein UML Anwender erstellt Klassendiagramme und beschreibt Use Cases inklusive Verhalten. Wenn man dazu ein Werkzeug verwendet, dass es einem leicht macht, Änderungen umzusetzen, so kann man sich damit das Verständnis für ein neues Themengebiet – entschuldigung, eine neue Problemdomäne – inkrementell erarbeiten. In dieser Form von Erkenntnisgewinn liegt ein wesentlicher Wert der Modellierung.

Oft wird ein Modell zur Dokumentation des Originals verwendet. Der Nutzen entsteht in der Regel dadurch, dass das Modell in einer Form erstellt wird, die sich leichter erschließen lässt als die Form des Originals – sei es, weil das Modell solche Details ausblendet, die für das Problemverständnis⁴ nicht notwendig sind, oder weil die Darstellung des Modells eingängiger sein mag als die Erscheinung des Originals – vgl. Diagramme und Quelltext. Insgesamt ist ein Modell sicher gut geeignet, um Wissen über das Original zugänglich zu machen und, z.B. in einem Team, zu verbreiten.

In der Softwareentwicklung ist es nun leider oft so, dass in Analogie zu physischen Modellen, davon ausgegangen wird, dass die Erstellung eines Originals anhand eines vorgegebenen Modells in der Art erfolgen muss, dass das Original vollkommen neu, allerdings unter Beachtung der Modellvorlage, zu erstellen sei. Außerdem ist das Verhältnis von Modell und Original in der Software-Entwicklung etwas verzwickt (vgl. Abschnitt: Erstellung oder Transformation), so dass in der Praxis oft der Zusammenhang zwischen Modell und Original verloren geht, also die Dokumentation veraltet. Statt also ein formales Modell zu erstellen, dass zur Automatisierung im Entwicklungsprozess weiter verwendet wird, entsteht eben nur Dokumentation.

Es ist ja nicht untypisch, beim Entwurf neuer Produkte zunächst Modelle zu erstellen, die dazu dienen ausgewählte Produkteigenschaften im Vorfeld festzulegen oder zu verifizieren. Im Gegensatz zum Produktionsprozess von physischen Gütern muss man in der Software-Herstellung kein vollständig neues Werkstück nach Vorlage eines Modells oder Entwurfs herstellen. Vielmehr arbeitet man in der Softwareentwicklung mit der Beschreibung eines Systems, die nach und nach mit mehr Details angereichert wird, bis alle Details festgelegt sind, um das System „auf die ausgewählte Plattform setzen“ zu können. Daraus erwächst die Möglichkeit genau solche Details, die sich systematisch ergeben, automatisch anzureichern.

Konkret: Werden in einem Klassenmodell Entitäten modelliert, dann entscheidet man einmal, wie die Persistenz von Entitäten implementiert wird und kann dieses Detail systematisch auf alle Entitäten im Modell anwenden. Hinter der Aussage „ist eine Entität“ verbergen sich also Unmengen technischer Details, die allerdings aus dem Modell weg abstrahiert sind.

Es sind folglich zwei Mechanismen, die Modelle bei der Herstellung von Software wertvoll machen:

• Abstraktionen, durch die man es vermeiden kann, wiederkehrende Sachverhalte wieder und wieder zu beschreiben (DRY).
• Automatismen, die verwendete Abstraktionen erkennen und in der Lage sind, das Modell zu konkretisieren.

Beispielsweise ist @Entity eine bekannte Abstraktion für Persistenz, die von einer JPA Implementierung automatisch umgesetzt werden kann.

Wenn zu einer Problemdomäne die richtigen Abstraktionen und dazugehörende Umsetzungsmechanismen vorliegen, kann man das Modell für eine Problemlösung klein halten und damit den Produktivitätsgewinn bei der Herstellung von Systemen deutlich steigern.

Das Verhältnis eines Diagramms zu dem beschriebenen Modell ist bzgl. seiner Abstraktion gut vergleichbar mit dem Verhältnis einer Implementierung zum Algorithmus: Quick-Sort bleibt Quick-Sort, egal ob ich es in C, JavaScript oder Haskell implementiere! Ganz ähnlich ändert sich ein Ablauf auch nicht dadurch, dass ich ihn als Aktivitätsdiagramm der UML oder als Nassi-Shneiderman-Diagramm darstelle. Auch die Beziehungen zwischen fachlichen Entitäten sollten davon unberührt bleiben, ob man sie in einem UML Klassendiagramm oder in einem ER Diagramm aufzeichnet.

Betrachtet man das Verhältnis anders herum, so kommt man zu dem Punkt, dass Diagramme ein hervorragendes Mittel bieten, um gezielt einzelne Aspekte eines Modells zu beleuchten. Betrachtet man Diagramme als Modell, so verliert man die wertvolle Anwendung in der Herstellung des Systems. Diagramme als reine Bilder eignen sich höchstens zum Erkenntnisgewinn oder zur Dokumentation.

In diesem Zusammenhang möchte ich zunächst auf die Meta-Ebenen M0–M3 der OMG eingehen. Die OMG hat sich entschieden Modelle bezüglich der Relation „ist Instanz von“ gegeneinander abzugrenzen. Diese Abgrenzung ist hervorragend geeignet, um in der Frage, was „Softwerker“ (Architekten, Designer, Entwickler, ) im Grunde treiben, voran zu kommen.

Beginnen wir hierzu mit der Frage, wo denn der Quelltext eines Programms anzusiedeln ist. Die OMG beantwortet das klar mit: M1 bzw. der Modellebene. Gut, verwenden wir also die Aussage, dass ein konkretes Programm auf der Metaebene M1 anzusiedeln ist, als Ankerpunkt. Als nächstes wenden wir uns der Frage zu, wovon unser fiktives Programm denn eine Instanz ist. Gemäß OMG müssen wir dazu feststellen, welche Sprache verwendet wurde, um das Programm zu (be)schreiben. Im Modellierungsumfeld wäre das natürlich UML – schließlich verwendet man UML, um ein konkretes System zu beschrieben. In der Praxis stellt man aber auch häufiger fest, dass Programmiersprachen verwendet werden, um lauffähige Softwaresystem zu erstellen. Wie dem auch sei, gemäß der Abgrenzung der Metaebenen durch „Instantiierung“ müssen wir alle Sprachen und Notationen, die verwendet werden, um konkrete Systeme oder Programme zu beschreiben, auf der Metamodellebenen M2 ansiedeln. In diese Richtung kann man nun weiter forschen und nach dem Metamodell von UML oder z.B. auch Lisp und anderen Programmiersprachen fragen. Die OMG beantwortet das mit der MOF, der Meta Object Facility, die als Metametamodell auf der Ebene M3 angesiedelt ist. Als solche kann sie nicht nur zu Metamodellen wie UML, oder auch Java, instantiiert werden. Praktischer Weise kann MOF sich selbst beschreiben und deswegen als Instanz ihrer selbst gelten. Damit hat man dem unendlichen Fragen nach weiteren Metaebenen einen Riegel vorgelegt.

Doch schauen wir nun auf das konkrete Ende dieser Skala: M0, die Ebene der „endgültigen“ Instanzen. Hier haben wir konkrete Dinge vor uns, die nicht mehr instantiiert werden. Ziel des Entwicklungsprozess ist es, den Weg auf diese Ebene frei zu machen.

Oder weniger theoretisch: Als Anwender einer Software ist es mein Ziel, ein laufendes Programm zu benutzen, damit Daten zu erfassen womöglich zu bearbeiten und meist auch zu speichern. Hierin liegt der Wert für den Anwender. Bisweilen bekommt man den Eindruck man bezahle für den Erwerb des „Programms“. Aber wer beschäftigt sich schon damit, den Source-, Byte- oder Maschinen-Code zu lesen, den er gerade gekauft hat? Wohl die Wenigsten. Vielmehr schätzt man, dass man eine – wenn auch höchst formale – Beschreibung von komplexen Vorgängen erworben hat, die eine Maschine dazu in die Lage versetzt, dies Vorgänge auch durchzuführen. Der Entwicklungsprozess hat also sein Ziel erreicht, wenn auch eine Maschine, ohne jegliches Gemeinverständnis, mit der Beschreibung klar kommt.

Das Original, das man modelliert ist also das laufende System, nicht jedoch das ausführbare Programm und schon gar nicht der Source Code.

Wenn weder das ausführbare Programm noch sein Source Code das Original sind, zu dem man ein Modell erstellt, dann muss man anders erklären, warum Modellieren, Generieren und Transformieren so wertvolle Tätigkeiten sind:

Der Weg zu einem ausführbaren System ist schwer. Hat man das erst mal, dann ist der Sprung auf die M0 Ebene, also zum laufenden System, vergleichsweise⁵ einfach.

Nun ist Generierung auf der Modellebene nichts unglaublich neues. Man hat schon sehr früh damit aufgehört, den Maschinen Code direkt in den Speicher von Computern zu schreiben, um ein Programm laufen zu lassen. Denn auch in Assembler kann man kein direkt lauffähiges Programm schreiben. Assembler muss erst in Maschinen Code übersetzt werden, bevor man ihn ausführen kann – auch wenn das Übersetzen in diesem Fall eine recht einfache Transformation ist.

Wer etwas in der Geschichte der Software-Entwicklung kramt, wird schnell finden, dass der damalige Übergang von Assembler zu Hochsprachen einen enormen Produktivitätsgewinn gebracht hat. Nicht verwunderlich: Hochsprachen, selbst C⁶, sind doch deutlich abstrakter als Assembler. Die Compiler oder Interpreter fügen dann alle Details hinzu, die fehlen, damit ein hochsprachliches Programm auf eine Maschine laufen kann. Übrigens sollen auch damals viele Entwickler diesem „modernen Kram“ mit viel Skepsis gegenüber getreten sein. Man verliere doch viel Kontrolle, wenn man Assembler aufgäbe. Genug von Gestern! Wie könnte heute ein einigermaßen automatisierter Entwicklungsprozess aussehen?

Wie im Beispiel gezeigt generiert man aus einem „Modell“, meint häufig ein fachliches Klassenmodell, den Source Code und gelegentlich den SQL Code, mit dem sich die CRUD Primitive und einige Standardabfragen für alle Entitäten ausführen lassen. Dem kann man noch allerlei Artefakte zum Testen hinzufügen. Da das alleine noch keine besonders spannende Anwendung macht, wird der Code noch manuell erweitert und kommt dann zu Weiterverarbeitung. Bei Java wird der Byte Code in den Class Files von vielen Frameworks noch weiter angereichert. Das mag während des Builds oder währen des Ladens passieren – wird hier, als ein Schritt von vielen, nicht im Detail betrachtet. Interessant ist die Frage, wo man die Datenbank ansiedelt. Da eine klassische relationale Datenbank nach dem ausführen der DLL Skripte nur Beschreibungen über die Struktur der Daten enthält, liegt sie in diesem Diagramm in der M1 Ebene. Die Instanzen, also die Daten, kommen erst später dazu.

Was aber deutlich wird ist, dass das Arbeiten mit Modellen im allgemeinen Sinne nicht neu ist. Auch ist es nicht revolutionär, ein Modell automatisch in ein anderes Modell zu transformieren. In der Regel nutzt man diesen automatischen Schritt dazu, systematisch wiederkehrende Details in das Zielmodell einzubauen.

Dieses Hin und Her zwischen den Modellen ist (hoffentlich) kein Selbstzweck. In welche Richtung muss die Generierung gehen und wo hört man damit auf? Idealer Weise hört man dort auf, wo man das eigentliche Ziel – den Übergang von M1 zu M0 – oder im Klartext das Laufende System mit nur einem Knopfdruck bekommt. Ein wenig wie Continuous Delivery. Und wo liegt dieser Punkt? Das kann man nicht allgemeingültig festlegen, denn es hängt von der Plattfrom ab, die als Zielplattform zum Einsatz kommt. Erst wenn für jedes Detail des Zielsystems in jeder zu beachtenden Situation klar ist, das weitere Details von der Plattform zuverlässig aufgelöst werden, ist das Modell präzise genug.

Wenn ich mich zum Beispiel auf die Java Runtime abstütze, ist mit new FileOutputStream("name") genug darüber gesagt, dass ich eine Ausgabedatei benötige. Wenige „Stockwerke“ tiefer finde ich womöglich ein UN!X System und muss deswegen davon ausgehen, dass auf dem Weg zu meiner Ausgabedatei ein open("name",O_WRONLY|O_CREAT|O_TRUNC) oder ähnliches liegt. Das sind Details, die die JVM hinzufügt. Nun könnte man im Betriebssystem nachschauen, was sich hinter open() verbirgt und so fort.

So kommt man dann von Plattform zu Plattform. Eigentlich ist das nicht verwunderlich, haben wir doch alle gelernt, dass man Probleme mit "Divide and Conquer" solange klein schlägt, bis sie beherrschbar werden. Dadurch bekommt man einen hohen Stapel von Abstraktionen, von denen mache so universell einsetzbar sind, dass man sie selten verändern muss. Die nennt man dann „Plattform“ und viele bauen darauf. Auf jeden Fall hat sich die Automatisierung der Modelltransformationen innerhalb der Modellebene bereits über viele Jahrzehnte bewährt. Und wenn man einen Satz von Generatoren hat, dazu zähle man hier jetzt auch Compiler, Byte-Code-Weaver u.v.a.m., der aus einem hinreichend abstrakten Modell genau die Artefakte erzeugt, die zur der Zielplattform passen, so hat man einen effizienten Entwicklungsprozess. Wenn man diese nicht hat, so kann die Erstellung der passenden Generatoren leicht mühselig werden. Generatoren zu programmieren braucht oft mehr Abstraktion als Anwendungen zu schreiben. Wenn man es aber beherrscht, lohnt sich das.

ToDo