Verwenden Sie MDA/MDD/MDSD, also irgendeine Art von modellgesteuertem Ansatz?Wird es die Zukunft sein?

https://stackoverflow.com/questions/21091

09-06-2019
|

Frage

Programmiersprachen hatten in ihrer Geschichte mehrere (r)evolutionäre Schritte.Einige Leute argumentieren, dass modellbasierte Ansätze das nächste große Ding sein werden.Es gibt Tools wie openArchitectureWare, AndroMDA, Sculptor/Fornax Platform usw.die unglaubliche Produktivitätssteigerungen versprechen.Allerdings habe ich die Erfahrung gemacht, dass es am Anfang entweder ziemlich einfach ist, anzufangen, aber auch, dass man irgendwann stecken bleibt, wenn man etwas Unerwartetes probiert, oder dass es ziemlich schwierig ist, genügend Informationen zu finden, die einem sagen, wie man sein Projekt startet, weil Möglicherweise gibt es eine Menge Dinge zu beachten.

Ich denke, eine wichtige Erkenntnis, um etwas aus modellgesteuerten Dingen herauszuholen, besteht darin, zu verstehen, dass das Modell nicht unbedingt eine Reihe schöner Bilder oder ein Baummodell oder UML ist, sondern auch eine Textbeschreibung sein kann (z. B.eine Zustandsmaschine, Geschäftsregeln usw.).

Was denken Sie und was sagen Ihnen Ihre Erfahrungen?Gibt es eine Zukunft für die modellgesteuerte Entwicklung (oder wie auch immer Sie es nennen möchten)?

Aktualisieren: Es scheint kein großes Interesse an diesem Thema zu geben.Bitte teilen Sie mir mit, ob Sie (gute oder schlechte) Erfahrungen mit modellbasierten Ansätzen gemacht haben oder warum Sie der Meinung sind, dass diese überhaupt nicht interessant sind.

Lösung

Ich denke, es wird einige Zeit dauern, bis die Tools verfeinert werden und mehr Menschen Erfahrungen mit MDD sammeln.Wenn man aus MDD etwas herausholen will, muss man derzeit ziemlich viel investieren, sodass die Nutzung begrenzt bleibt.

Schauen Sie sich zum Beispiel openArchitectureWare an:Obwohl es ziemlich robust ist und eine grundlegende Dokumentation vorhanden ist, fehlt Dokumentation zum Innenleben und es gibt immer noch Probleme mit der Skalierbarkeit, die nicht dokumentiert sind – vielleicht wird das besser, wenn Xtext und Xpand neu geschrieben werden.

Aber trotz dieser Einschränkungen ist die Generierung selbst mit oAW ganz einfach, Sie können in Xtend und Xpand problemlos durch Ihre Modelle navigieren und durch die Kombination mehrerer Workflows zu größeren Workflows können Sie auch sehr komplexe Dinge erledigen.Bei Bedarf können Sie auf Java zurückgreifen, sodass Sie eine große Flexibilität bei der Gestaltung Ihrer Modelle haben.Auch das Schreiben einer eigenen DSL mit Xtext in oAW ist schnell erledigt, dafür erhält man sein Metamodell, einen Parser und einen sehr schönen Editor quasi kostenlos.Außerdem können Sie Ihre Modelle grundsätzlich von überall beziehen, z.eine Komponente, die eine Datenbank in ein Metamodell umwandeln kann und entsprechende Modelle ohne großen Aufwand geschrieben werden können.

Ich würde also sagen, dass sich MDD immer noch im Aufbau befindet, da die Tools und die Erfahrung damit zunehmen.Es kann bereits erfolgreich eingesetzt werden, wenn Sie über das nötige Fachwissen verfügen und bereit sind, es in Ihrem Unternehmen voranzutreiben.Letztendlich denke ich, dass es eine sehr gute Sache ist, da viel Klebercode (auch bekannt als Kopieren und Einfügen) generiert werden kann und sollte.Das mit MDD zu machen, ist meiner Meinung nach eine sehr schöne und strukturierte Methode, die die Wiederverwendbarkeit erleichtert.

Andere Tipps

Haftungsausschluss:Ich bin Entwickler von Geschäftsanwendungen.Die folgende Sichtweise ist sicherlich von meinen Erfahrungen in den Schützengräben der Unternehmens-IT geprägt.Mir ist bewusst, dass es noch andere Bereiche der Softwareentwicklung gibt.Insbesondere in der industriellen und/oder eingebetteten Systementwicklung könnte die Welt anders aussehen.

Ich denke, MDSD ist immer noch zu sehr an die Codegenerierung gebunden.

Die Codegenerierung ist nur dann sinnvoll, wenn Ihr Code viel Rauschen enthält und/oder sich sehr wiederholt.Mit anderen Worten, wenn sich Ihr Code nicht hauptsächlich auf die wesentliche Komplexität konzentrieren kann, sondern mit zufälliger Komplexität verunreinigt ist.

Meiner Meinung nach geht der Trend bei aktuellen Plattformen und Frameworks genau dahin, zufällige Komplexität zu beseitigen und den Anwendungscode auf die wesentliche Komplexität zu konzentrieren.

Diese neuen Plattformen/Frameworks nehmen der MDSD-Bewegung also viel Wind aus den Segeln.

DSLs (textuelle) sind ein weiterer Trend, der versucht, die alleinige Konzentration auf die wesentliche Komplexität zu ermöglichen.Während DSLs als Quelle für die Codegenerierung verwendet werden können, sind sie nicht in erster Linie an die Codegenerierung gebunden.DSLs (insbesondere interne DSLs) ermöglichen grundsätzlich die Interpretation/Ausführung zur Laufzeit.[Die Generierung von Laufzeitcode liegt irgendwo dazwischen].

Auch wenn DSLs oft zusammen mit MDSD erwähnt werden, denke ich, dass sie tatsächlich eine Alternative zu MDSD darstellen.Und angesichts des aktuellen Hypes nehmen sie auch der MDSD-Bewegung den Schwung.

Wenn Sie das Ziel erreicht haben, versehentliche Komplexität endgültig aus Ihrem Code zu entfernen (ich weiß, das ist fiktiv), dann sind Sie bei einem Textmodell Ihres Geschäftsproblems angekommen.Das lässt sich nicht weiter vereinfachen!

Schöne Kästchen und Diagramme bieten keine weitere Vereinfachung oder Erhöhung der Abstraktionsebene!Sie mögen für die Visualisierung gut sein, aber selbst das ist fraglich.Nicht immer ist ein Bild die beste Darstellung, um Komplexität zu erfassen!

Darüber hinaus führt der aktuelle Stand der in MDSD involvierten Werkzeuge zu einer weiteren Ebene zufälliger Komplexität (denken Sie an:Synchronisierung, Diffing/Merging, Refactoring ...), was das ultimative Ziel der Vereinfachung im Grunde zunichte macht!

Schauen Sie sich zur Veranschaulichung meiner Theorie das folgende ActiveRecord-Modell an:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Ich glaube nicht, dass man das noch einfacher machen kann.Auch jede grafische Darstellung mit Kästchen und Linien wäre keine Vereinfachung und würde keinen größeren Komfort bieten (denken Sie an Layout, Refactoring, Suche, Differenzierung ...).

Modellgetriebene Entwicklung gibt es schon seit sehr langer Zeit.

Der erfolgreichste der frühen Versuche war James Martins „Integrated Engineering Facility“, das immer noch existiert und von CA unter dem wirklich uncoolen Markennamen „Coolgen“ vermarktet wird.

Warum hat es dann nicht die Welt erobert, wenn es so gut war?

Nun, diese Tools sind gut darin, die einfachen Dinge einfacher zu machen, aber sie machen die schwierigen Dinge nicht einfacher, und in vielen Fällen machen sie die schwierigen Dinge schwieriger!

Sie können Stunden damit verbringen, eine grafische 4GL-Modellierungssprache davon zu überzeugen, „das Richtige zu tun“, wenn Sie wissen, dass es trivial wäre, das Richtige in Java/C/SQL oder was auch immer zu programmieren.

Ich denke, dass es möglicherweise keine endgültige Antwort gibt – daher das mangelnde „Interesse“ an dieser Frage.

Aber ich persönlich habe gemischte Erfahrungen mit MDA gemacht.Das einzige Mal, dass ich gute Erfahrungen gemacht habe, war mit großartigen Tools – ich habe früher TogetherSoft verwendet (ich glaube, sie sind irgendwie bei Borland gelandet) – sie waren einer der ersten, der die Bearbeitung eingeführt hat, bei der es sich nicht um „Codegenerierung“ handelte, sondern tatsächlich um die Bearbeitung des Codes/ Modell direkt (damit man den Code oder das Modell bearbeiten konnte, es war alles eins).Sie hatten auch Refactoring (das war das erste Mal, dass ich mich daran erinnere, dass es Post-Smalltalk-Umgebungen gab).

Seitdem habe ich nicht gesehen, dass MDA an Beliebtheit weiter zugenommen hat, zumindest nicht im Mainstream, also scheint es, was die Beliebtheit angeht, nicht die Zukunft zu sein (das ist also die Antwort).

Natürlich ist die Popularität nicht alles, und die Dinge werden tendenziell zurückkommen, aber im Moment denke ich, dass MDA+Tools von vielen als „Assistenten-basierte Codegenerierungs“-Tools angesehen werden (unabhängig davon, was es wirklich ist), also ich Ich denke, es wird einige Zeit oder vielleicht nie dauern, bis es wirklich losgeht.

Eines der Probleme von MDD besteht darin, dass es, da es auf einer höheren Abstraktionsebene arbeitet, Entwickler erfordert, die auch auf der Abstraktionsebene aufsteigen können.Dadurch wird die Zahl der Entwickler, die solche Methoden verstehen und anwenden können, erheblich reduziert.

Bitte teilen Sie mir mit, ob Sie (gute oder schlechte) Erfahrungen mit modellbasierten Ansätzen gemacht haben oder warum Sie der Meinung sind, dass diese überhaupt nicht interessant sind.

Ich denke, dass die Mitwirkenden hier Teil des „No Silver Bullet“-Lagers sind (das bin ich auf jeden Fall).Wenn MDA funktionieren würde (gleichbedeutend mit „riesigen Einsparungen“), wüssten wir es mit Sicherheit.Die Frage ist:Wie weit können Sie „Meta“ gehen und gleichzeitig Ihr System überschaubar halten?Dies war der Wendepunkt in UML 2.0, als ein formelleres Meta-Meta-Modell eingeführt wurde.Bisher habe ich noch keine reale Nutzung der Modellierungsleistung von UML 2.0 gesehen (aber meine Welt ist eher begrenzt).Außerdem haben Sie bei einem modellbasierten Ansatz nur zwei Möglichkeiten:Generieren Sie Code oder verfügen Sie über eine Laufzeit, die Ihr Modell ausnutzt.Der ultimative Codegenerator ohne Einschränkungen heißt „human“, während die ultimativen Laufzeiten in den 4GLs zu finden sind (wie hoch ist heutzutage die aktuelle Zahl?).Vielleicht würde das den Mangel an Begeisterung erklären.

Wir bei itemis (www.itemis.com) nutzen häufig modellgesteuerte Softwareentwicklung.Bisher haben wir wirklich gute Erfahrungen gemacht.Natürlich ist es kein Allheilmittel, aber es trägt zur Verbesserung der Softwarequalität und damit zu einem größeren Nutzen für unsere Kunden bei.

Modellgesteuerte Entwicklung wird genau dann die Zukunft sein, wenn die verwendeten Modelle genauso flexibel sein können wie das Schreiben des Codes, den sie generieren soll.Ich denke, der Grund, warum es im Moment nicht so gut läuft, liegt darin, dass es schwierig ist, das gleiche „Round-Tripping“ durchzuführen, das textbasierte Programmiersprachen seit Jahrzehnten machen.

Bei textbasierten Programmiersprachen ist die Änderung des Modells so einfach wie die Änderung einiger Codezeilen.Mit einer grafischen Programmiersprache (auch bekannt als MDD-Diagramm wie UML) müssen Sie einen Weg finden, dieses Modell vollständig zurück in sein textbasiertes Äquivalent zu übersetzen (das bereits von vornherein ausdruckseffizient war), und das gelingt ihm sehr, sehr chaotisch sein.

Meiner Meinung nach kann MDD nur dann nützlich sein, wenn es von Grund auf so ausdrucksstark und flexibel ist wie sein textbasiertes Gegenstück.Der Versuch, bestehende Top-Down-Grafikdesignsprachen (wie UML) für Tools zu verwenden, die von Natur aus von unten nach oben unter Verwendung geschichteter Abstraktionen erstellt werden (wie Programmiersprachen), führt zu einem großen Impedanzungleichgewicht.Ich kann es nicht genau sagen, aber in MDD fehlt immer noch etwas, das es so nützlich machen würde, wie die Leute es behaupten würden ...

Dies ist eine sehr späte Antwort, aber ich suche derzeit nach MDD-Tools als Ersatz für Rose RT, das leider durch Rhapsody ersetzt wird.Wir sind im Echtzeit-, eingebetteten und verteilten C++-Bereich tätig und holen viel aus MDD heraus.Wir versuchen, auf ein besseres Tool umzusteigen und es in unserem sehr großen Unternehmen häufiger einzusetzen.Aus einigen der hier genannten guten Gründe ist es ein harter Kampf.

Ich stelle mir MDD nur eine Ebene über dem Compiler vor, genauso wie der Compiler über der Assembly liegt.Ich möchte ein Tool, mit dem ich als Architekt das Anwendungsframework entwickeln und die Codegenerierung (Skripte) 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 vollständige UML-Klassen und Zustandsdiagramme erstellen, die den gesamten Code enthalten, der zum Generieren der Anwendung und/oder Bibliothek erforderlich ist.

Es ist wahr, dass man mit Code alles machen kann, aber ich würde die Vorteile von MDD grob so zusammenfassen:

Einige Leute erstellen das Anwendungsframework und die Middleware-Adapter und binden diese an das MDD-Tool.Sie bauen das „Haus“.
Andere Leute erstellen komplette Klassen, Diagramme und Zustandsautomaten-Übergangscode.Dadurch können sie sich auf die Anwendung statt auf das „Haus“ konzentrieren.
Es ist leicht zu erkennen, wenn Leute ein seltsames Design haben, da das Diagramm der Code ist.Wir haben nicht alle erfahrene Entwickler und es ist schön, junge Leute auf diese Weise zu fördern.
Meistens ist es der fiese Zustandsmaschinencode, der in so etwas wie einem mobilen Robotikprojekt passieren kann.Ich möchte, dass Leute Zustandsdiagramme erstellen, die ich verstehen, kritisieren und mit denen ich daran arbeiten kann.
Sie können auch nette Refactoring-Vorgänge wie das Ziehen von Vorgängen und Attributen nach oben in Vererbungsketten oder zu anderen Klassen usw. durchführen.Das gefällt mir besser, als in Akten zu wühlen.

Schon während ich das schreibe, wird mir klar, dass man alles im Code machen kann.Ich mag ein dünnes Tool direkt über dem Code, um Einheitlichkeit zu gewährleisten, das Design zu dokumentieren und ein etwas einfacheres Refactoring zu ermöglichen.

Das Hauptproblem, auf das ich stoße und auf das ich keine gute Antwort habe, ist, dass es für solche Modelle keinen Standardsatz an Funktionalität und Dateiformat gibt.Die Leute machen sich Sorgen, dass der Verkäufer weggeht und dann stecken bleibt.(Das ist uns im Prinzip bei Rose RT passiert.) Beim Quellcode gibt es das nicht.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 habe noch kein solches Tool gefunden, aber ich versuche, ein paar Anbieter dazu zu bringen, mir zuzuhören und vielleicht Geld anzunehmen, um dies zu ermöglichen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow