"UML ist das Schlimmste, was MDD jemals passiert ist." Warum?


17

William Cook schrieb in einem Tweet :

" UML ist das Schlimmste, was MDD je passiert ist. Zum Glück ist vielen Menschen jetzt klar, dass ... "

Ich möchte die Gründe für diese Behauptung kennen (anscheinend beziehe ich mich nicht auf seine persönliche Meinung).

Ich habe bemerkt, dass viele Leute da draußen UML nicht so sehr mögen. Erwähnenswert ist auch, dass er in der akademischen Welt tätig ist, in der UML der heilige Gral effektiven Entwurfs und Modellierens ist.


15
Ich würde sagen, MDD ist das Schlimmste, was MDD je passiert ist.
Michael Borgwardt

Antworten:


39

Nun, ich bin der Akademiker, der den ursprünglichen Tweet gepostet hat. Tweets sind keine wissenschaftlichen Artikel. Sie sind Werbung, und ich denke, sie können auch umstritten sein. Hier sind meine Follow-up-Tweets:

1) UML wurde erstellt, um OO-Designs zu modellieren. Dies hat zur Folge, dass Sie den Code eines Systems modellieren und nicht das Verhalten des Systems. UML ist auf der falschen Ebene.

2) Die Idee, dass 7 (oder 13) Diagrammformate in UML alles abdecken können, ist verrückt. Was ist mit GUIs, Web-Wireframes, Autorisierung usw.?

3) UML hat die Idee gefördert, dass Modelle grafisch sein müssen. Lächerlich! Text- und Grafikmodelle sind nützlich und oft austauschbar

4) UML ist gleichzeitig zu groß und komplex und gleichzeitig sehr begrenzt. Stereotype und Profile sind für verwendbare Erweiterungen nicht wirksam.

Beachten Sie, dass ich nicht unbedingt sage, dass UML schlecht ist. Ich sage nur, dass es dem Ziel der "modellgetriebenen Entwicklung" nicht hilft, woran ich interessiert bin. Ich verstehe den Kommentar zu "Heiligem Gral" nicht.


10
+1 für das Finden und Beantworten einer Frage auf prog.SE zu Ihrem eigenen Tweet!
Warren P

Modellgetriebene Entwicklung schien mir immer ein visuelles Modell zu sein. Und wenn nicht UML, was dann? (Beachten Sie, ich habe MDD noch nie gemocht und ich hasse UML. Aber ich bin bereit, MDD-sans-UML eine Chance zu geben. Was sollte ich versuchen?
Warren P

1
@Warren P: Was magst du an MDD und UML nicht?
Dan_l

1
Ich habe meine Antwort entfernt, weil ich mich eindeutig geirrt habe, was Sie meinten. Aber ich stehe zu der Aussage, dass UML, wie jede Sprache, ein Kommunikationswerkzeug ist, kein Designwerkzeug. Sie antworteten: "Viele Programmiersprachen haben das Wort" Sprache "im Namen, aber das bedeutet nicht, dass sie nur für die Kommunikation und nicht für die Ausführung bestimmt sind." Sie würden COBOL auch nicht als Entwurfswerkzeug verwenden.
pdr

Ich denke, der Kommentar "Heiliger Gral" bezieht sich auf die Häufigkeit des Unterrichts.

8

UML ist das Äquivalent zu einem Schraubenzieher und einem Hammer, die zusammengeklebt und als "Universal Fastening Tool" bezeichnet werden. Theoretisch kann es verwendet werden, um eine Menge Dinge sehr detailliert darzustellen. In der Praxis handelt es sich um eine Reihe von schlecht integrierten Werkzeugen, die behaupten, ein einziges Werkzeug zu sein, was die Ausführung einer einzelnen Aufgabe weitaus schwieriger macht, als zunächst ein geeignetes Werkzeug zu haben.



3

Ich denke, es gibt auch einen Grund, warum MDD das Schlimmste ist, was UML passiert ist (warum sollten wir sonst die UML2 haben, die wir haben?), Aber das für den Moment ignorieren ...

MDD = Model Driven <Design | Development>. Die Idee ist, Lösungen auf einer Abstraktionsebene zu entwickeln, die der Problemdomäne entspricht - das heißt, es wird versucht, Lösungen für Probleme in der natürlichsten Syntax zum Ausdrücken dieser Lösungen auszudrücken. Die Problemdomäne selbst ist durch ein Betriebsmodell gekennzeichnet (dh durch ein Modell, das vom Computer ausgeführt werden kann). MDD kann also ein sehr attraktiver Ansatz sein, wenn auch einer mit zwei Hauptanforderungen:

  1. Man muss in der Lage sein, diese Sprache in eine für die Computerausführung geeignete Form zu kompilieren (das Modell muss funktionsfähig sein ); und
  2. Man muss eine Modellierungssprache für die Problemdomäne erstellen.

Meines Erachtens sollte mit den UML2-Bemühungen Punkt 1 angesprochen werden, wahrscheinlich unter der Annahme, dass die industrielle Erfahrung mit UML gezeigt hat, dass Punkt 2 für einige große Teilmengen von Problembereichen erfüllt ist. Unglücklicherweise erfüllt UML, und ich denke, dass William Cook genau darauf gekommen ist, Punkt 2 bei weitem nicht, was den Umfang der Probleme angeht, an die gedacht wurde. Ich spreche nicht aus persönlicher Erfahrung, aber ich denke, die industrielle Erfahrung mit der Verwendung von MDD mit UML hat zwei gemeinsame Ergebnisse:

  • Entweder muss der aus der UML generierte Quellcode optimiert werden, um diese kleinen Lücken zwischen dem UML-Design und den Programmanforderungen zu schließen (was Entwickler dazu zwingt, mit generiertem Code zu arbeiten, der unterschiedliche Standards für die Wartbarkeit aufweist, und die Anwendbarkeit der UML-Artefakte auf die Implementierung verringert ); ODER
  • Die UML ist mit vielen Details überfüllt, was ihre Verwendbarkeit als Sprache für die Kommunikation über das Design einschränkt.

    In beiden Fällen ist das Versprechen von MDD unerfüllt. UML kann als das Schlimmste angesehen werden, das MDD widerfahren ist, da es die Aufmerksamkeit der MDD-Tool-Entwickler auf den Ausschluss von Modellen lenkt, die möglicherweise tatsächlich funktionieren (wenn auch für eine kleinere Anzahl von Softwareproblemen).


  • -2

    UML ist großartig, solange es nur eine Modellierungssprache ist. Wenn Sie versuchen, MDD mit UML zu verbinden, um eine grafische Ansicht zu erhalten, ist dies unbrauchbar. MDD wäre sowohl ohne UML als auch ohne MDD großartig.

    Nehmen wir an, UML und MDD haben sich heute geschieden, um ein besseres Leben nicht mehr zusammen zu führen :-)


    Es ist auf keiner Ebene "großartig". Ein Benutzer der katastrophalen ADA-Programmiersprache (Booch) hat einige kindliche Diagramme erstellt und sich mit ein paar ernsthafteren Ansätzen für Klassendiagramme zur Erstellung von UML vertraut gemacht. UML entwickelte sich sofort zu einem Umsatzbringer großer Softwareanbieter. Es war schrecklich, aber es hat sich bewährt, indem man einfach neue Diagrammtypen (die mit UML datiert sind) wie Sequenz, Datenfluss usw. abgelegt hat. Es gibt nichts Erweiterbares daran. Keine Datenbankschemata, keine Ebenendiagramme, es ist voll von Lücken und gleichzeitig voll von nutzlosen Diagrammen.
    Rick O'Shea
    Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
    Licensed under cc by-sa 3.0 with attribution required.