Modellgetriebene Softwareentwicklung mit UML und Java

• Startseite
• > heise Developer Artikel-Foren
• > Modellgetriebene Softwareentwicklung mit...
• > Davon kann man nur abraten

• << Beitrag >>
• << Thread >>
• Beantworten
• E-Mail
• Neuer Thread
• Thread-Anzeige einblenden

Bewertung dieses Beitrags:

Davon kann man nur abraten (Editiert vom Verfasser am 06.01.13 um 16:11)

Software-Generierung in bestimmten Bereichen ist eine feine Sache.
Wir verwenden seit mehreren Jahren einen MDA Ansatz für die
Generierung von SOA Schnittstellen. Trotzdem würde - wenn wir auf der
grünen Wiese neu Anfagen würde - niemand mehr mit UML / MDA arbeiten
wollen. Der einzige Vorteil - die Visualisierung - wiegt die
Nachteile nicht auf.

  Ich habe noch nie ein PIM gesehen, wo das Wort 'platform
independent' gerechtfertigt gewesen wäre, weil man immer auch die
technische Machbarkeit beim Modellieren berücksichtigen muss (wenn
beispielsweise Java keine Mehrfachvererbung zulässt, kann ich das
nicht einfach im UML so modellieren. Solche Dinge gelten
grundsätzlich für alle technischen Rahmenbedingungen, die sich im
Modell niederschlagen können).

 Wie weit der Standard UML ist, begreift man dann, wenn man die
Freude hat, das Modelliertool zu wechseln.

  Jedes nicht triviale Modell wird auch mit der visualisierten
Darstellung von UML nicht mehr einfach zu begreifen sein. Vor allem
wenn der Modellierer sich nicht um verständliche Modelldarstellungen
bemüht. Und sobald ein Generator-relevantes Stück Information in UML
nicht mehr in einem einfachen Kästchen visualisiert werden kann, geht
auch die Übersicht verloren. Es gibt übrigens tatsächlich auch Dinge,
die lassen sich als z.B. einfache Listen in Text schneller und
übersichtlicher darstellen ..

  Ich kann nur jedem Anraten, als erster Generatorschritt das Modell
zu validieren. Wie im Artikel erwähnt ist UML komplex. Modellierer
können gutgemeint alles mögliche "zeichnen", was für den Generator
überhaupt keinen Sinn macht. Man ist gezwungen, die Menge der
erlaubten Konstrukte in einem UML-Modell vor der Generierung
einzugrenzen, weil sonst jede Fehlersuche nicht trivial wird. Dabei
ist auch zu erwähnen, dass die Komplexität von UML eine wasserdichte
Validierung schwer macht. Statt weniger hat man mehr Aufwand (Pflege
von Modellen, Generatoren und zusätzlich Pflege von Validatoren) und
neue Fehlerquellen (z. B. wenn der Validator unberechtigterweise
meckert bzw. wenn er nicht meckert, der Generator dann aber nicht das
gewünschte Resultat generiert).

  Aus dem letzten Punkt sieht man auch schon, wo es bei UML extrem
krankt: Das Meta-Meta Modell lässt viel zu viele Dinge zu und mit UML
Profilen kann man diese Teile nicht "entfernen" (es gibt gute Gründe,
wieso neben MOF auch eMOF entstanden ist). Der Modellierer muss also
nicht nur UML kennen, sondern auch welche Teile daraus wie zu
verwenden sind, damit am Schluss das gewünschte Generat resultiert.
Oder mit anderen Worten: Die gewünschte Abstraktion durch das Modell
ist zwangsweise löchrig. Statt weniger / einfacher werden die Dinge
komplexer.

  Hat man eine gewisse Anzahl Modelle und muss aufgrund neuer
Anforderungen neue Informationen in den Modellen hinterlegen, ist der
Migrationsaufwand hoch, weil man das von Hand machen muss.

  Auf der Werkzeugseite ist UML auch keine tolle Erfahrung. Neben der
Komplexität der Modellierungstools wird man auch schnell mit
Alltagsproblemen der Entwicklung konfrontiert: Wie verzweigt, patched
oder mergt man ein UML Modell? Das geht nach meiner Erfahrung mit
einfachen, textbasierten Abstraktionen (=Modellen) gut, mit UML und
teuere Werkzeuge höchstens unbefriedigend schlecht. Wie kann ich ein
Modell automatisiert migrieren, weil ein Wechsel diese erfordert? Gar
nicht - man muss sowas mühsam von Hand machen. Bei Abstraktionen in
Form einfacher, strukturierter Textdateien, annotierten Java
Interfaces, XML-Dateien, etc. kein Problem. Etc. etc.

Wie gesagt, Software-Generierung ist aus meiner Erfahrung in
bestimmten Bereichen toll. Aber der superflexible, supergenerische
MDA Ansatz mit UML - einfach mal was pinseln und die Artefakte werden
daraus vollautomatisch richtig generiert - ist unter reelen
Bedingungen ein realitätsfremder Traum.
Wenn man sich vorher über die Anforderungen klar ist, kann man
einfachere Abstraktionen wählen, um Artefakte (Code, Deskriptoren,
WSDLs, etc.) zu generieren, die Informationen redundant oder
aufeinander abgestimmt enthalten müssen. Mit pragmatischeren Ansätzen
wie JET, Velocity, JAXB, Xtext, etc. ist man i. d. R. besser bedient.
Es ist aber darauf zu achten, dass man den Dokumentations-Aspekt - wo
UML punktet - gut abdecken kann.

BTW: Die Information im Artikel bezüglich oAW ist übrigens falsch.
Das Projekt wurde aufgeteilt und lebt unter der Ägide von Eclipse
flott weiter, wobei v. a. Xtext/Xpand deutlich an Fahrt gewonnen hat.

Edit/Zusatz: Mit der ganzen Fixierung auf UML als Abstraktion hat man
MDSD wohl am meisten geschadet. UML mag für strukturelle Modelle (z.
B. Klassenhierachien) brauchbar sein, aber es ist wohl kein Zufall,
das:
- der im Artikel gelinkten "Best Practices im Rahmen der
modellgetriebenen Softwareentwicklung" UML gar nicht gross erwähnt ..
- bei Prozesse, Event- und Verarbeitungsketten, wo nicht Struktur
sondern Zeitlichkeit im Fokus steht - man sich nicht auf generische
UML-Modelle sondern auf BPMN standardisiert hat.

• Nutzungsbedingungen
• << Beitrag >>
• << Thread >>
• Beantworten
• E-Mail
• Neuer Thread
• Thread-Anzeige einblenden

• In Thread-Darstellung zeigen
• In Eingangsreihenfolge zeigen