Was halten Sie von modellgetriebener Softwareentwicklung?

Ich verwende MDSD in einem Projekt mit IBM Rational Rhapsody für C ++. Das Modell ist ziemlich nah an UML, also haben wir nicht wirklich eine Domain-spezifische Sprache. Trotzdem würde ich behaupten, MDSD zu benutzen. Aus meiner Erfahrung gibt es viele Vorteile mit MDSD:

a) Die Verwendung von MDSD hilft, eine SW-Architektur auf eine anspruchsvolle Ebene zu bringen. Sie arbeiten immer auf einer sehr abstrakten Ebene und denken über das Gesamtbild nach. Cowboy-Codiersoftware fehlt in der Regel eine gute Architektur, da ein Entwickler im Detail steckt. Mit MDSD sehe ich eine Tendenz in meiner Arbeit, Probleme mit angemessen großen Klassen, schönen Mustern oder einfach besserem Code zu lösen.

b) Die Großbilddokumentation der SW ist bei MDSD tendenziell besser. Natürlich gibt es Tools, die aus Ihrem Code automatisch ein Klassendiagramm generieren. Aber diese Diagramme bestehen aus 1000 Klassen und Sie sehen den Aspekt des Interesses nicht. Mit MDSD zeichnen Sie speziell einen Aspekt des Systems und das gleiche Diagramm wird auch verwendet, um einen Teil Ihres Codes zu generieren.

c) Modellierung hilft, mit einer inhärenten Systemkomplexität umzugehen. Ich würde sagen, einige Systeme sind einfach zu komplex, um ohne Unterstützung durch computergestütztes Design gebaut zu werden. Niemand würde eine CPU ohne die Hilfe von großen SW-Tools entwerfen. Verwenden Sie SW, um Ihnen zu helfen, noch komplexere SW zu schreiben.

d) Die Verwendung von MDSD hilft, die Richtlinien für den Codierungsstil einzuhalten. Es gibt keinen besseren Weg, einen kohärenten Code-Stil zu erhalten, als den Code durch einen Regelsatz generieren zu lassen.

Es gibt natürlich auch einige Nachteile von MDSD: d) Wenn Sie ein Modell haben, möchten Sie, dass jede Codezeile von diesem Modell kommt. Und es kann schwierig sein, externe Bibliotheken zu einem Projekt hinzuzufügen. Entweder Sie leben mit der Tatsache, dass Ihr System auf externen Komponenten basiert oder Sie erfinden das Rad neu, um es in Ihr Modell zu bekommen.

e) Modellierungstools können Probleme bei der Verwendung von Versionstools haben. Quellcode ist normalerweise einfacher zu verschmelzen als ein Modelldiagramm. Dies zwingt ein Team, vom Kopier-Editier-Merge zu einem Lock-Edit-Merge-Workflow zu wechseln.

MDA ist ein bisschen überladenes Konzept. Manchmal bedeutet das, dass UML oder ein anderer Diagrammtyp in ausführbaren Code umgewandelt wird. Ich habe nie gesehen, dass dies mit den heute verfügbaren Tools gut funktioniert. Es führt normalerweise dazu, dass Projekte wirklich schnell Ergebnisse erzielen und dann einen Alptraum verursachen, da die verfügbaren Tools nicht wirklich große Teams unterstützen, die an visuellen Diagrammen arbeiten, und weil die Leute anfangen, in den Diagrammen zu arbeiten, sowie den generierten Code.

Ich habe etwas gesehen, das sehr nach domänenorientiertem Design aussieht und als MDA bezeichnet wird, wenn Sie meinen, dass ich dafür bin: -)

Ich denke, es ist vorzuziehen. Das wollte ich mit dieser Frage über MVC-ARS statt MVC. Der ARS (Action / Representation / State) ist vom Entwurf her im Modell enthalten und verhindert das Überladen von Controller oder View.

Bei der modellgetriebenen Softwareentwicklung geht es nicht nur um MDA, es gibt eine Reihe anderer Ansätze, einschließlich des vielleicht populäreren Ansatzes für domänenspezifische Sprachen.

Sicher, der Code ist "ein" Modell, aber das Erfassen eines übergeordneten Modells in einer DSL ist eine noch prägnantere Art, dieselbe Absicht auszudrücken. Der Schlüssel ist, immer Ihren Code aus dem Modell zu generieren, anstatt eine unabhängige Änderung des generierten Codes zuzulassen.

Es gibt viele verfügbare Werkzeuge und jede Menge veröffentlichtes Material, einschließlich Fallstudien, um Ihnen zu sagen, wie Sie Ihre eigenen Generatoren bauen können, wenn Sie nicht glücklich sind, einen Standardgenerator zu kaufen. Dies gibt Ihnen möglicherweise mehr Kontrolle als die Arbeit mit einer allgemeinen Programmiersprache.

Es klingt sicher nett, aber ich habe es noch nicht praktisch umgesetzt sehen können.

Ich halte es so: Der Code ist das Modell. So sind Ihr Modell und Ihr Code immer auf dem neuesten Stand: -)

Nur um zwei Bücher einzuwerfen, die ich nützlich fand, um MDA zu verstehen, wie oben erwähnt, ist es ein breites Thema.

• MDA Distilled - Prinzipien der modellgetriebenen Architektur. (Mellor)
• Real-life MDA: Lösung von Geschäftsproblemen mit Model Driven Architecture (Guttman)

Sie müssen nicht alle die Guttman lesen, um die Idee zu bekommen, da die Fallstudien langweilig werden, aber das Intro war angenehm zu lesen.

MDA erschwert normalerweise die Integration der Geschäftsregeln in die serverseitige Schicht, da die Modellansichtszuordnung von generiertem Code gehandhabt wird und funktionale Hooks als Ereignis-Responder bereitgestellt werden.

Ich habe noch kein MDA-Tool gesehen, das so leistungsfähig wie Forté (oder UDS, jetzt tot) + Express war. Ich stelle mir vor, dass ein MDA mit den Fähigkeiten von Forté plus bessere Muster, um eine unabhängige Service-Schicht zu erreichen (wie ActiveRecord oder EntityTransactionManager-Muster) eine Killer-App für jede Plattform wäre.

Das Problem bei der tatsächlichen Anwendung, die auf den dreistufigen MDA-Ansatz abzielt, ist, dass diese extrem schwierig einzurichten und an spezifische Anforderungen anzupassen sind. Denken Sie nur an ABAP- und SAP-Tarife