Haftungsausschluss: Ich bin ein Entwickler von Geschäftsanwendungen. Die folgende Sichtweise ist sicherlich geprägt von meinen Erfahrungen in den Gräben der Unternehmens-IT. Mir ist bewusst, dass es andere Bereiche der Softwareentwicklung gibt. Gerade in der industriellen und / oder eingebetteten Systementwicklung könnte die Welt anders aussehen.
Ich denke MDSD ist immer noch zu sehr an die Code-Generierung gebunden.
Code-Generierung ist nur nützlich, wenn Ihr Code viel Rauschen enthält und / oder sehr repetitiv ist. Mit anderen Worten, wenn sich Ihr Code nicht hauptsächlich auf die wesentliche Komplexität konzentrieren kann, sondern durch zufällige Komplexität belastet ist.
Meiner Meinung nach besteht der Trend in aktuellen Plattformen und Frameworks gerade darin, zufällige Komplexität zu beseitigen und den Anwendungscode auf essentielle Komplexität zu konzentrieren.
Diese neuen Plattformen / Frameworks nehmen also den Wind aus den Segeln der MDSD-Bewegung.
DSLs (textuelle) sind ein weiterer Trend, der versucht, den Fokus auf essentielle Komplexität zu legen. Während DSLs als Quelle für die Codegenerierung verwendet werden können, sind sie nicht primär an die Codegenerierung gebunden. DSLs (vor allem interne DSLs) lassen es grundsätzlich offen, um zur Laufzeit interpretiert / ausgeführt zu werden. [Laufzeitcode-Generierung liegt irgendwo dazwischen].
Selbst wenn DSLs oft zusammen mit MDSD erwähnt werden, sind sie meiner Meinung nach eine echte Alternative zu MDSD. Und angesichts des aktuellen Hypes nehmen sie auch der MDSD Bewegung den Rücken.
Wenn Sie das Ziel erreicht haben, zufällige Komplexität aus Ihrem Code zu entfernen (ich weiß, dass dies fiktiv ist), dann sind Sie zu einem Textmodell Ihres Geschäftsproblems gelangt. Dies kann nicht weiter vereinfacht werden!
Schöne Boxen und Diagramme bieten keine weitere Vereinfachung oder Erhöhung der Abstraktionsebene! Sie mögen gut für die Visualisierung sein, aber selbst das ist fraglich. Ein Bild ist nicht immer die beste Darstellung, um die Komplexität zu erfassen!
Darüber hinaus fügt der aktuelle Stand der MDSD-Tools eine weitere Ebene der zufälligen Komplexität hinzu (Denken Sie: Synchronisation, Diffing / Merging, Refactoring ...), was das ultimative Ziel der Vereinfachung im Grunde aufhebt!
Betrachten Sie das folgende ActiveRecord-Modell als Beispiel für meine Theorie:
%Vor%Ich denke nicht, dass das einfacher sein kann. Auch jede graphische Darstellung mit Kästchen und Linien wäre keine Vereinfachung und würde keine Bequemlichkeit mehr bieten (denke über Layout, Refactoring, Suche, Diffing ...).
Programmiersprachen hatten mehrere (r) evolutionäre Schritte in ihrer Geschichte. Einige Leute argumentieren, dass modellgetriebene Ansätze The Next Big Thing sein werden. Es gibt Tools wie OpenArchitectureWare, AndroMDA, Sculptor / Fornax Platform usw., die unglaubliche Produktivitätssteigerungen versprechen. Ich habe jedoch die Erfahrung gemacht, dass es am Anfang ziemlich einfach ist, anzufangen, aber auch, wenn man etwas versucht, das unvorhergesehen ist oder ziemlich schwierig ist, genügend Informationen zu finden, die dir sagen, wie du dein Projekt starten sollst Es gibt eine Menge Dinge zu beachten.
Ich denke, eine wichtige Erkenntnis, etwas aus modellgetriebenem Etwas herauszuholen, besteht darin zu verstehen, dass das Modell nicht unbedingt eine Menge schöner Bilder oder Baummodelle oder UML ist, sondern auch eine Textbeschreibung (zB eine Zustandsmaschine) , Geschäftsregeln etc.).
Was denkst du und was sagt dir deine Erfahrung? Gibt es eine Zukunft für die modellgetriebene Entwicklung (oder wie immer man das nennen mag)?
Update: Es scheint kein großes Interesse an diesem Thema zu geben. Bitte lassen Sie mich wissen, wenn Sie irgendwelche (guten oder schlechten) Erfahrungen mit modellgetriebenen Ansätzen haben oder warum Sie denken, dass es überhaupt nicht interessant ist.
Modellgetriebene Entwicklung gibt es schon sehr lange.
Der erfolgreichste dieser frühen Versuche war James Martins Integrated Engineering Facility ", die immer noch von CA unter dem ernsthaften uncoolen Markennamen" Coolgen "vertrieben wird.
Warum hat es die Welt nicht übernommen, wenn es so gut war?
Nun, diese Werkzeuge sind gut darin, die einfachen Dinge einfacher zu machen, aber sie machen die harten Sachen nicht einfacher und machen in vielen Fällen härtere Sachen härter!
Sie können Stunden damit verbringen, eine grafische 4GL-Modellierungssprache zu überreden, "das Richtige zu tun", wenn Sie wissen, dass die richtige Programmierung in Java / C / SQL oder was auch immer trivial ist.
Ich denke, es wird Zeit brauchen, bis die Tools verfeinert werden, mehr Leute Erfahrungen mit MDD sammeln. Im Moment, wenn Sie etwas von MDD bekommen wollen, müssen Sie ziemlich viel investieren, so dass seine Verwendung begrenzt bleibt.
Wenn man sich openArchitectureWare anschaut: Während es ziemlich robust ist und grundlegende Dokumentation existiert, fehlt die Dokumentation der inneren Abläufe und es gibt immer noch Probleme mit der Skalierbarkeit, die undokumentiert sind - vielleicht wird das besser, wenn Xtext und Xpand neu geschrieben werden.
Aber verachten Sie diese Einschränkungen, die Erzeugung selbst ist mit oAW ziemlich einfach, Sie können Ihre Modelle in Xtend und Xpand wie ein Zauber navigieren und indem Sie mehrere Arbeitsabläufe in größere Arbeitsabläufe integrieren, können Sie auch sehr komplexe Dinge tun. Bei Bedarf können Sie auf Java zurückgreifen, so dass Sie sehr flexibel sind, was Sie mit Ihren Modellen tun können. Auch das eigene DSL mit Xtext in oAW zu schreiben, ist schnell erledigt, trotzdem bekommst du dein Meta-Modell, einen Parser und einen sehr netten Editor quasi kostenlos. Auch können Sie Ihre Modelle grundsätzlich von überall, z. Eine Komponente, die eine Datenbank in ein Metamodell umwandeln kann und entsprechende Modelle können ohne großen Aufwand geschrieben werden.
Also würde ich sagen, MDD baut immer noch auf, da Tools und Erfahrungen damit zunehmen. Sie kann bereits erfolgreich eingesetzt werden, wenn Sie über das notwendige Fachwissen verfügen und bereit sind, es in Ihrem Unternehmen zu betreiben. Am Ende denke ich, es ist eine sehr gute Sache, weil eine Menge Klebstoffcode (aka Kopierpaste) erzeugt werden kann und sollte. Dies mit MDD zu tun ist eine sehr nette und strukturierte Methode, die meiner Meinung nach die Wiederverwendbarkeit erleichtert.
Ich denke, vielleicht gibt es keine endgültige Antwort - daher das fehlende "Interesse" an dieser Frage.
Aber ich habe persönlich gemischte Erfahrungen mit MDA gemacht. Die einzige Zeit, in der es eine gute Erfahrung war, war mit großartigen Tools - ich benutzte TogetherSoft (ich glaube, dass sie irgendwie bei Borland gelandet sind) - sie waren eine der ersten, die eine Bearbeitung einführten, die keine "Code-Generierung" war, sondern die Bearbeitung des Codes / Modell direkt (so können Sie Code oder das Modell bearbeiten, es war alles eine Sache). Sie hatten auch Refactoring (das war das erste Mal, dass ich es nach Smalltalk-Umgebungen erinnere).
Seit dieser Zeit habe ich MDA nicht mehr in der Popularität wachsen sehen, zumindest in der Mainstream, so in Bezug auf die Popularität scheint es nicht die Zukunft zu sein (so dass die Art der Antworten es).
Natürlich ist Popularität nicht alles, und Dinge, die dazu neigen, wiederzukommen, aber vorläufig denke ich, dass MDA + -Tools von vielen als "Assistenten-basierte Code-Generation" -Tools angesehen werden (unabhängig davon, was es wirklich ist) ) Ich denke, es wird einige Zeit dauern oder vielleicht nie, dass es wirklich abhebt.
Wir, bei itemis (www.itemis.com), verwenden modellbasierte Softwareentwicklung sehr. Bis jetzt hatten wir wirklich gute Erfahrungen. Es ist keine Wunderwaffe, aber es hilft, die Softwarequalität zu verbessern und somit mehr für unsere Kunden zu nutzen.
Eines der Probleme von MDD ist, dass es, da es auf einer höheren Abstraktionsebene arbeitet, Entwickler benötigt, die auch auf Abstraktionsebene gehen können. Das reduziert das Universum der Entwickler, die solche Methoden verstehen und anwenden können, erheblich.
Dies ist eine sehr späte Antwort, aber ich suche derzeit nach MDD-Tools, um Rose RT zu ersetzen, die leider von Rhapsody verdrängt wird. Wir sind im Echtzeit-, Embedded- und verteilten C ++ - Bereich und wir haben eine Menge von MDD. Wir versuchen, zu einem besseren Werkzeug überzugehen und das Werkzeug in unserem sehr großen Unternehmen zu verbreiten. Es ist ein harter Kampf wegen einiger der hier erwähnten Gründe.
Ich denke, dass MDD nur eine Ebene über dem Compiler liegt, genauso wie der Compiler oberhalb der Assembly liegt. Ich möchte ein Tool, mit dem ich als Architekt das Anwendungsframework entwickeln und die Codegenerierung (Skripts) umfassend bearbeiten kann, um dieses Framework und die Middleware, die wir für die Nachrichtenübermittlung verwenden, zu verwenden. Ich möchte, dass die Entwickler komplette UML-Klassen und Zustandsdiagramme erstellen, die den gesamten Code enthalten, der zum Generieren der Anwendung und / oder Bibliothek benötigt wird.
Es ist richtig, dass Sie alles mit Code machen können, aber ich würde grob die Vorteile von MDD wie folgt zusammenfassen:
Schon während ich das eintippe merke ich, dass Sie alles mit Code machen können. Ich mag ein dünnes Werkzeug direkt über dem Code, um Einheitlichkeit zu erzwingen, das Design zu dokumentieren und ein etwas einfacheres Refactoring zu ermöglichen.
Das Hauptproblem, auf das ich stoße, für das ich keine gute Antwort habe, ist, dass es für solche Modelle keine Standardfunktionen und kein Dateiformat gibt. Leute sorgen sich darum, dass der Verkäufer weggeht und dann festsitzt. (Im Grunde hatten wir das mit Rose RT.) Das haben Sie nicht mit dem Quellcode. Sie hätten jedoch die neueste Version des Tools und den Kurscode, den Sie zuletzt generiert haben :). Ich wette, dass der Nutzen das Risiko überwiegt.
Ich muss das Tool noch so finden, aber ich versuche, ein paar Verkäufer dazu zu bringen, mir zuzuhören und vielleicht Geld anzunehmen, um dies zu ermöglichen.
Model Driven Development wird die Zukunft sein, wenn und nur wenn die Modelle, die es verwendet, so flexibel sein können wie das Schreiben des Codes, den es erzeugen soll. Ich denke, der Grund, warum es im Moment nicht so gut läuft, ist, dass es schwierig ist, das gleiche "Runden-Trip" zu machen, das textbasierte Programmiersprachen seit Jahrzehnten machen.
Bei textbasierten Programmiersprachen ist das Ändern des Modells so einfach wie das Ändern einiger Zeilen Code. Mit einer grafischen Programmiersprache (auch bekannt als MDD-Diagramm wie UML) müssen Sie eine Möglichkeit finden, dieses Modell vollständig auf sein textbasiertes Äquivalent (das bereits von vornherein ausgesprochen effizient war) zu übersetzen und es kann sehr, sehr chaotisch.
IMHO, der einzige Weg, MDD kann immer nützlich sein, wenn es von Grund auf so ausdrucksstark und so flexibel wie sein textbasiertes Gegenstück aufgebaut ist. Der Versuch, vorhandene Top-down-Programmiersprachen (z. B. UML) für Werkzeuge zu verwenden, die von Grund auf mit geschichteten Abstraktionen (z. B. Programmiersprachen) erstellt werden, führt zu einer großen Impedanzfehlanpassung. Ich kann es nicht genau sagen, aber es gibt immer noch etwas in MDD, das es so nützlich machen würde, wie die Leute behaupten, es sei ...
Bitte lassen Sie mich wissen, ob Sie irgendwelche (guten oder schlechten) Erfahrungen mit modellgetriebenen Ansätzen haben oder warum Sie denken, dass es überhaupt nicht interessant ist.
Ich denke, die Mitwirkenden hier sind Teil des "No Silver Bullet" Camps (ich bin definitiv). Wenn MDA funktioniert (entspricht "großen Einsparungen"), würden wir es wissen, das ist sicher. Die Frage ist: Wie weit "Meta" können Sie gehen, während Ihr System überschaubar bleibt? Dies war der Wendepunkt in UML 2.0, als sie ein formelleres Meta-Metamodell einführten. Bis jetzt habe ich noch keine reale Nutzung der Modellierungskraft von UML 2.0 gesehen (aber meine Welt ist ziemlich begrenzt). Außerdem haben Sie nur zwei Möglichkeiten mit einem modellgesteuerten Ansatz: Code generieren oder eine Laufzeitumgebung nutzen, die Ihr Modell ausnutzt. Der ultimative constraint-freie Code-Generator wird "Mensch" genannt, wohingegen die letzten Laufzeiten in den 4GLs gefunden wurden (was ist die aktuelle Anzahl heutzutage?). Vielleicht würde das den Mangel an Begeisterung erklären.