|
 |
|
|
|
|
|
 |
|
|
(30.04.05 08:30)
|
|
|
|
|
|
Der goldene Hammer der MDA ist die UML und als wichtige Variante davon die ausführbare UML (Engl. Executable UML, kurz xUML). Verfechter der MDA gehen ja soweit zu behaupten, dass mit xUML endlich das präzise Beschreiben von ausführbaren Modellen möglich werde, und dies die kostenintensive Implementierung einer vorab spezifizierten Lösung in einer herkömmlichen GPL hinfällig machen würde. Erreicht werden soll dies durch das Erhöhen des Abstraktionsgrades, um sich von den technischen Belangen einer Programmiersprache lösen zu können. Anstatt also wie bisher ein Problem mit einer GPL wie Java, C++ oder C# zu lösen, wird in xUML programmiert oder – weil das besser zum Begriff Abstraktion passt – eben modelliert. In diesem Zusammenhang frage ich mich übrigens, woher dieser tiefe Aberglaube rührt, dass grafische Modelle grundsätzlich leichter zu erstellen oder besser zu lesen seien als z.B. rein textuelle Repräsentationen?
|
|
|
|
|
|
Wie dem auch sei: Grundsätzlich gehen die MDA-Befürworter davon aus, dass mit xUML modelliert wird, während man in einer GPL nur programmiert bzw. implementiert. Hier schwingt ein Werturteil mit, das darauf hinaus läuft, Modellierung als im Vergleich zur Programmierung höherwertige Aufgabe anzusehen. Wer auch immer auf diese absonderliche Idee gekommen ist, er oder sie hat da etwas ganz Entscheidendes verpasst: Das Programmieren in einer GPL ist Modellieren. Denn beim Entwerfen von Modellen geht es um Abstraktion, um die wichtige Unterscheidung zwischen relevanten und nicht relevanten Aspekten, welche in die Lösung einfliessen müssen. Auch der Code in einer GPL ist letztlich nur ein Modell, allerdings ein sehr detailliertes, vielschichtiges und noch dazu komplexes, da es einen Zusammenzug von vielen unterschiedlichen Aspekten, insbesondere der fachlichen und programmtechnischen Ebene bildet. Es ist diese Vielschichtigkeit, welche häufig zu ungewollter Komplexität führt, und gegen die tatsächlich etwas unternommen werden muss. Doch leider hilft uns hier weder UML noch xUML wirklich weiter.
Ich behaupte: xUML ist die Programmiersprache, die niemand braucht! Warum? Weil wir keine missratene GPL benötigen, die umständlich und unpräzise ist, die ungebührlich einschränkt und - verglichen mit einer echten GPL – auch zu ausdrucksschwach ist.
|
|
|
|
|
|
Was wir brauchen, ist die Möglichkeit, näher an den fachlichen Problemen zu arbeiten und dabei direkt die Konzepte und Begriffe aus der Fachdomäne verwenden zu können, d.h. wir wollen erreichen, dass wir uns direkter und unmittelbarer mit den fachlichen Fragestellungen auseinander setzen können. Der grosse Nutzen einer solchen domänengetriebenen Entwicklung besteht somit darin, dass wir uns bei der Umsetzung der fachlichen Erfordernisse nicht um technische Details kümmern müssen, die sich durch die Verwendung einer GPL und entsprechender technischer Infrastruktur ergeben. Die konsequente Trennung zwischen fachlichen und technischen Problemen strukturiert den Lösungsraum entlang der jeweiligen Anforderungen und erlaubt uns die Konzentration auf die im jeweiligen Kontext relevanten Probleme. Indem wir verhindern, dass sich die fachlichen und technischen Probleme in einem einzigen Modell, dem Programmcode, vermischen, schaffen wir ausdrucksstärkere Modelle, die besser verstanden, gewartet und weiter entwickelt werden können.
|
|
|
|
|
|
Es geht also nicht darum, das Programmieren in einer GPL abzuschaffen, sondern es geht darum zu verhindern, dass sich fachliche und technische Belange in einem Modell vermischen. Denn diese Vermischung führt dazu, dass die Lösung ungewollt komplexer als nötig wird, da für ihr Verständnis stets mindestens zwei Ebenen –die fachliche und die programmtechnische – berücksichtigt werden müssen. Selbst wenn nämlich das in einer GPL umgesetzte ausführbare und testbare Modell domänengetrieben entwickelt worden ist, und die gewählten Abstraktionen so gewählt und benannt wurden, dass sie die fachlichen Aspekte möglichst direkt einfangen und so weit als möglich unverfälscht abbilden, verschleiern technische Notwendigkeiten, wie Syntax und Idiome der verwendeten GPL oder nötige technische Muster und Konzepte die Sicht auf die fachliche Essenz der Lösung. Und dies auch dann, wenn man alles daran setzt, ausdrucksstarken Code zu schreiben, z.B. indem man schnittstellenbasierte Minisprachen verwendet und seine Objekte quasi kontextbezogen Rollen spielen lässt. Denn auch hier wird das Domänenmodell durch die konkrete Syntax der verwendeten GPL mehr oder weniger stark verwässert. Wird zudem auf Änderungsfreundlichkeit und Erweiterbarkeit des Codes wert gelegt, dann kommen entsprechende technische Muster hinzu, die die Lösung noch einmal in Richtung Technik verschieben und so zusätzlich von den ursprünglichen fachlichen Problem ablenken. Eine strikte Trennung der fachlichen und technischen Belange ist daher wünschenswert und wohl auch entscheidend, wenn es darum geht, Verständlichkeit und Wartbarkeit der Lösung sowohl auch fachlicher als auch auf technischer Ebene zu gewährleisten.
|
|
|
|
|
|
Genau aus diesem Grund sind Domänensprachen so wertvoll. Denn eine Domänensprache ist auf das jeweilige Fachgebiet, wie z.B. Versicherungspolicen, Content Management, Maschinensteuerung, etc. zugeschnitten und erlaubt die Beschreibung von Lösungsmodellen für fachliche Problemstellungen, und dies eben losgelöst von technischen Belangen. So können wir in einer DSL konkreter und abstrakter zugleich arbeiten. Konkreter, weil wir näher am fachlichen Problem bleiben können und abstrakter, weil wir gleichzeitig in der Lage sind, losgelöst von technischen Details zu Werke zu gehen. Diese technischen Belange sind zwar nach wie vor relevant und wollen gelöst werden, aber sie gehören definitiv nicht ins fachliche Modell, sondern sind Teil der technischen Umsetzung. Diese Umsetzung bildet dabei einen Verbund von aktiv generiertem GPL-Code auf der Basis der Domänenmodelle, Framework- und Bibliothekscode und handgeschriebenem GPL-Code, der Aspekte abdeckt, welche sich in einer DSL nicht mit vertretbarem Aufwand einfach, verständlich und vor allem auch testbar umsetzen lassen. Bei dieser Form der domänengetriebenen Entwicklung erfolgt eine eigentliche Trennung der Verantwortlichkeiten auf höherer Ebene, die weit über die herkömmliche eher technisch orientierte auf lose Kopplung und enge Kohäsion ausgerichtete Systemstrukturierung hinaus geht.
|
|
|
|
|
|
Bei all dem hilft uns xUML nicht im geringsten! Eben weil es sich nur um eine weitere – noch dazu ziemlich schlechte – GPL handelt, ist durch sie nichts gewonnen. Wie jede GPL muss auch die xUML vielen Zwecken dienen können, was gegen ihre Verwendung als DSL spricht; denn auch die Idee der UML-Profile zur domänenspezifischen Anpassung der xUML hilft hier nicht wirklich weiter. Letztlich muss der Versuch scheitern, mit xUML eine anpassbare abstrakte GPL als Basis für die domänengetriebene Entwicklung anzubieten . Denn eben weil xUML nur eine GPL ist, krankt sie an den gleichen Problemen wie jede andere GPL auch.
Donänengetriebene Entwicklung mit Hilfe von DSLs und GPLs ist ein mächtiger Ansatz, der uns helfen kann, bessere Software, welche die an sie gestellten Anforderungen erfüllt, schneller zu entwickeln, xUML dagegen ein gefährlicher Irrweg.
-nemo :-)
Über diesen Artikel diskutieren.
|
|
|
Zugriffe heute: 3 - gesamt: 1363.
|
|
|
