Warum machen wir noch nicht alle eine modellgetriebene Entwicklung? [geschlossen]

19

Ich glaube fest an Model Driven Development und denke, dass es die Möglichkeit bietet, Produktivität, Qualität und Vorhersehbarkeit zu steigern. Wenn man sich MetaEdit anschaut, sind die Ergebnisse erstaunlich. Mendix in den Niederlanden wächst sehr, sehr schnell und erzielt großartige Ergebnisse.

Ich weiß auch, dass es viele Probleme gibt

  • Versionierung von Generatoren, Templates und Framework
  • Projekte, die einfach nicht für die modellgetriebene Entwicklung geeignet sind (nicht genügend Wiederholungen)
  • höhere Risiken (wenn das erste Projekt fehlschlägt, haben Sie weniger Ergebnisse als bei einer traditionelleren Entwicklung)
  • etc

Dennoch scheinen diese Probleme lösbar zu sein, und der Nutzen sollte den erforderlichen Aufwand überwiegen.

Frage : Was sind für Sie die größten Probleme, bei denen Sie nicht einmal an eine modellgetriebene Entwicklung denken?

Ich möchte diese Antworten nicht nur für mein eigenes Verständnis verwenden, sondern auch als mögliche Quelle für eine Reihe interner Artikel, die ich schreiben möchte.

KeesDijk
quelle
21
Ich glaube fest an keine Programmier- oder Entwicklungsmethode. Fast alle von ihnen sind für etwas nützlich; Keiner ist für alles das Beste. Ich glaube nicht, dass eine "wahre Gläubigerfrage" nach P.SEs Maßstäben konstruktiv ist.
David Thornley
4
@ David Thornley: Danke für den Kommentar, aber ich weiß nicht, ob der "wahre Gläubige" irgendetwas damit zu tun hatte, konstruktiv zu sein oder nicht. Ich bin sehr zufrieden mit den Antworten und es hat sehr geholfen. Aus meiner Sicht war es sehr konstruktiv. Ich glaube auch, dass viele Antworten für viele Menschen, die sich für MDD interessieren, viel Wert haben.
KeesDijk
1
@ David Thornley danke für den Kommentar bei der Abstimmung nach unten! Ich weiß es wirklich zu schätzen, wenn Leute Kommentare dazu abgeben, wann sie abstimmen.
KeesDijk
Wie Martin Fowler es ausdrückt ( martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html ): nicht genügend Werkzeugunterstützung ( martinfowler.com/bliki/ProjectionalEditing.html ).
Minghua

Antworten:

54

Es gibt keinen goldenen Hammer. Was in einer Domäne gut funktioniert, ist in einer anderen ziemlich nutzlos. In der Softwareentwicklung liegt eine gewisse Komplexität, die von keinem magischen Werkzeug entfernt werden kann.

Man könnte auch argumentieren, dass die Generierung von Code nur nützlich ist, wenn die Sprache selbst (oder das Framework) nicht hoch genug ist, um leistungsfähige Abstraktionen zu ermöglichen, die MDD relativ sinnlos machen würden.

user281377
quelle
14
Fred Brooks nannte es "No Silver Bullet", aber die Essenz Ihres Punktes und sein Argument sind identisch: cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Adam Crossland
5
KeesDijk: IMO, der Umgang mit Wiederholungen ist der Kern der Programmierung. Die meisten Strukturelemente in Programmiersprachen, von Schleifen, Rekursionen, Funktionen bis hin zu OO-Konzepten usw., sind für den Umgang mit der einen oder anderen Art von Wiederholung vorgesehen.
user281377
3
Fred Brooks hat einige Papiere aus den 50ern und 60ern, die noch entlarvt werden müssen. Lesen Sie das Buch "Mythical Man Month" (das auch den Aufsatz "No Silver Bullet" enthält).
Berin Loritsch
4
1987? Heck, Fred Brooks veröffentlichte 1975 ein Buch, das nichts von seiner Wichtigkeit oder Genauigkeit eingebüßt hat ( en.wikipedia.org/wiki/The_Mythical_Man-Month ). Nein, ich glaube nicht, dass die Prinzipien von No Silver Bullet heute weniger zutreffen als damals. Wie @ammoQ so prägnant formuliert: In der Softwareentwicklung steckt eine gewisse Komplexität ... "Jetzt können Sie verschiedene Ansätze und Techniken, Frameworks und Methoden ausprobieren, aber zum größten Teil versuchen sie nur, die gesamte Komplexität in den Griff zu bekommen Ein bestimmter Eimer, der nicht
verschwindet
4
@KeesDijk: Die Idee hinter "No Silver Bullet" wird in naher Zukunft nicht überholt sein. Brooks unterteilt Programmierschwierigkeiten anhand von Begriffen aus der Philosophie in das Wesentliche und das Zufällige. Seine Prämisse ist, dass es eine Menge wesentlicher Schwierigkeiten beim Programmieren gibt, und alle neuen Methoden, die man wirklich tun kann, sind, die zufälligen Schwierigkeiten zu beseitigen. In diesem Aufsatz sagte er, dass die dramatischste Entwicklung Shrink-Wrap-Software war, die im Vergleich zu kundenspezifischer oder kundenspezifischer Software eine ganze Menge Programmierung darstellt, die einfach nicht durchgeführt werden muss.
David Thornley
16

Interessante Frage! Ich gebe zu, ich bin kein Fan, aber dann habe ich mehrmals versucht, modellgetriebene Entwicklung in Projekten einzusetzen, die zu einigen der Probleme passen, die Sie gerade angesprochen haben.

Hier ist meine Liste der Gründe:

  • Lernkurvenmodellierungswerkzeuge haben sich so schnell entwickelt, dass ich kaum Ingenieure finden kann, die das Werkzeug genau verstehen. Ich finde immer noch, dass Sie nur so gut sind wie Ihr Modellierungswerkzeug. Zugegeben, viele der folgenden Probleme könnten auf dieses eine Problem zurückgeführt werden - wenn Sie der Meinung sind, dass ein Tool zu einschränkend ist, wissen Sie es möglicherweise nicht gut genug.
  • Zu strukturiert - Persönlich war ich in Situationen, in denen ich feststellte, dass das Modellierungswerkzeug einfach zu strukturiert war, um alles zu beschreiben, was ich beschreiben musste. Und sobald ich zum Zeichnen einiger Teile des Modells außerhalb des Werkzeugs übergehe, verfallen die Dinge schnell, wenn Leute anfangen, außerhalb des Werkzeugs zu treiben, um die Informationen zu finden.
  • Optimierungskosten für das Tool - Jedes Mal, wenn ich versucht habe, Code automatisch zu generieren, habe ich den Code manuell überarbeitet, sobald ich gesehen habe, was das Tool für richtig hielt. Ich weiß, dass sich dieses Problem nach ein paar Runden verringert, aber das bedeutet, dass Sie die ersten Runden überleben müssen. Ich hatte allgemein das Gefühl, dass wir einen Schlag ins Maul gespielt haben - Modell erstellen -> Code generieren -> Code reparieren -> Modell aktualisieren -> Modell reparieren, spülen und wiederholen.
  • Modellkonfigurationsmanagement - Da das Modell große Teile des Projekts beschreibt, ist das Modell-CM auf einer bestimmten Ebene übergreifender als der erstellte Code. Das Kompartimentieren der Modellierungsdateien ist eine Kunst für sich - machen Sie es falsch und es kommt häufig zu einem Entwickler-Deadlock oder zu veralteten Modellen, wenn die Leute aufgeben und sich dem Code widmen.
  • time to market - Ich hatte definitiv Probleme in einer Situation, in der dringend funktionierende Software benötigt wurde. Wenn das Projekt und das Team klein genug sind, sehe ich keinen Grund, Zeit mit einem Modellierungswerkzeug zu verschwenden, wenn die Zeit für das Codieren und Testen aufgewendet werden kann. Nicht jedes Projekt ist groß genug, um solche Investitionen zu erfordern.
  • Fehlerkosten - Wenn Projekte nicht mehr mit Modellierungswerkzeugen arbeiten, sind die Fehlerkosten hoch. Um die Werkzeuge zu verwenden, muss jeder Entwickler einbezogen werden. Das ist eine große Investition in Training und praktisches Lernen und ein sehr kostspieliger Fehler, wenn jemand das Modell schlecht eingestellt hat. Ich habe die Erfahrung gemacht, dass es zwei oder drei Releases dauern kann, bis das Modell richtig ist - so viele Projekte überleben Modellierungsfehler nicht lange genug, um die Vorteile zu realisieren.
bethlakshmi
quelle
Vielen Dank ! Tolle Liste! Ich muss zustimmen, dass dies berücksichtigt werden muss, und wenn Sie es falsch machen, sind die Kosten des Scheiterns in der Tat sehr hoch. Eine Frage: Haben Sie mehr Erfahrung mit UML-Falltools von DSL-Tools wie MetaEdit?
KeesDijk
Sicher @KeesDijk - UML! Besonders Rational Rose, aber auch ein bisschen Rational SW Architect.
Bethlakshmi
12

Es wurde bereits zitiert, aber No Silver Bullet spricht den Punkt ziemlich gut an:

Die Essenz einer Software-Entität ist ein Konstrukt aus ineinandergreifenden Konzepten: Datensätze, Beziehungen zwischen Datenelementen, Algorithmen und Funktionsaufrufe. Diese Essenz ist insofern abstrakt, als ein solches konzeptuelles Konstrukt unter vielen verschiedenen Darstellungen dasselbe ist. Es ist dennoch hochpräzise und detailreich.

Ich glaube, dass der schwierige Teil der Erstellung von Software darin besteht, dieses konzeptuelle Konstrukt zu spezifizieren, zu entwerfen und zu testen, und nicht darin, es darzustellen und die Wiedergabetreue der Darstellung zu testen. Wir machen immer noch Syntaxfehler, um sicher zu sein; Aber sie sind unscharf im Vergleich zu den konzeptionellen Fehlern in den meisten Systemen.

Wenn dies zutrifft, wird das Erstellen von Software immer schwierig sein. Es gibt von Natur aus keine Silberkugel.

Später weist Brooks auf das Konzept der "automatischen Programmierung" hin:

Seit fast 40 Jahren antizipieren und schreiben Menschen über "automatisches Programmieren" oder die Erstellung eines Programms zur Lösung eines Problems aus einer Erklärung der Problemspezifikationen. Einige schreiben heute, als ob sie erwarten, dass diese Technologie den nächsten Durchbruch bringt.

Parnas bedeutet , dass der Begriff für Glanz verwendet wird, nicht für semantischen Inhalt, zu behaupten, „Kurz gesagt, die automatische Programmierung ist schon immer ein Euphemismus mit einer höheren Programmiersprache für die Programmierung als für den Programmierer derzeit zur Verfügung stand.“

Er argumentiert im Wesentlichen, dass es in den meisten Fällen die Lösungsmethode ist, nicht das Problem, dessen Spezifikation angegeben werden muss.

Grundsätzlich würde ich argumentieren, dass MDD nur ein weiterer Euphemismus für das Programmieren mit einer höheren Programmiersprache ist als bisher verfügbar.

Das heißt nicht, dass das Programmieren in einer höheren Sprache nicht helfen kann - tatsächlich kann es oft. Der Kern des Problems bleibt jedoch derselbe: Egal wie großartig ein Tool oder eine Sprache ist, am Ende des Tages müssen Sie alle Probleme durchdenken und die Probleme lösen. Das Beste, was jedes Tool oder jeder Prozess tun kann, ist, den "Fuzz" zu entfernen, damit Sie sich auf das wichtige Thema konzentrieren können, das, wie Brooks sagte, "die Spezifikation , das Design und das Testen dieses konzeptuellen Konstrukts " ist.

Daniel Pryden
quelle
3
Brooks hat vor 30 Jahren darüber gestritten, was?
Paul Nathan
Vielen Dank für diese gut formulierte Antwort. Ihr letzter Absatz fasst meine Gefühle auch ziemlich gut zusammen. Und wenn Sie festgestellt haben, dass "die übergeordnete Programmierung" Ihnen dabei helfen kann, viele andere gute Antworten auf diese Frage zu berücksichtigen.
KeesDijk
10

Weil nicht jede Programmierung objektorientiert ist, was alle MDD-Tools zu erwarten scheinen. UML selbst basiert auf der Annahme von Objekten. Sicher, Sie können Sequenzdiagramme verwenden, um Funktionen zu modellieren, aber das ist oft umständlich.

Weil es Programmierer wie mich gibt, die mit TDD mehr Fortschritte und Ergebnisse erzielen als mit MDD.

Weil Modellieren! = Programmieren.

Weil das Kosten-Nutzen-Verhältnis auf der Kostenseite zu hoch und auf der Nutzenseite zu niedrig war. Dies hat sich wahrscheinlich geändert, seit ich mir MDD das letzte Mal angesehen habe. Damals mussten Sie für ein Tool, das mäßig MDD-fähig wäre,> $ 6000 / Sitz (USD) bezahlen.

Da ein Modell, das eine Funktion ausreichend beschreibt, um den Code zu generieren, als Modell nicht mehr nützlich ist.

Weil es Programmierer wie mich gibt, die nur Modelle auf hohem Niveau verwenden und dann die Details mit Code ausarbeiten. Im Code sehen Sie die Dinge anders als in der Modellierungssoftware.

Das sind einige der Gründe, warum ich persönlich keine MDD mache. Ich war dem ausgesetzt, aber nichts hat mich zu einem Konvertiten gemacht. Vielleicht bin ich zu alt. Vielleicht bin ich zu neu in der Schule (was auch immer das ist). Es ist einfach kein Werkzeug, mit dem ich mich amortisieren konnte.

Berin Loritsch
quelle
Vielen Dank! Die Modellierung! = Programmierung verdient eine eigene Frage. Ich kenne viele Leute, die anderer Meinung sind. Die besseren Ergebnisse mit TDD und Modell, die für mich eine Funktion beschreiben, bedeuten, dass das verwendete Modell nicht die richtige Abstraktionsebene aufweist. Wenn Sie das Modell auf Codeebene schreiben, gehen alle Vorteile verloren. Die Kosten fallen nicht mehr an, Sie können Eclipse kostenlos modellieren, die MS dsl-Tools sind kostenlos, es gibt kostenlose UML-Tools und EA ist nicht so teuer. Die Details gehen immer noch in den Code ein. Sie fügen sie in ein Framework ein, das ein Modell verwenden kann. Wenn Sie das zweite Mal generieren, haben Sie die Vorteile.
KeesDijk
Ich denke, für jeden, den Sie finden können, der mit Ihnen übereinstimmt, kann ich zumindest eine Übereinstimmung finden, die mit mir in Bezug auf Programmierung übereinstimmt! = Modellierung. Beim Programmieren geht es um Abstraktion, und Modellierung kann bei der Abstraktion hilfreich sein, ist jedoch nicht immer das richtige Werkzeug für die jeweilige Aufgabe.
Berin Loritsch
Einverstanden !
KeesDijk
7

Microsoft / Apple / Google pusht es nicht :)

Welche Art von Entwicklung popularisiert wird, hat viel mit Werkzeugen, Unterstützern und Evangelisation zu tun. Es ist sehr schwer, mit etwas ohne großen Backer durchzukommen (Ruby on Rails ist vielleicht die Ausnahme, aber im Vergleich zu Java / C # / Python immer noch klein)

Homde
quelle
Okay, ich muss zustimmen. Obwohl Microsoft ein wenig mit dem Visual Studio Visualisierungs- und Modellierungs-SDK versucht, ist archive.msdn.microsoft.com/vsvmsdk kein Push.
KeesDijk
7

Aufgrund eines einfachen Gesetzes, das sich auf alle diese Modellierungswerkzeuge auswirkte, wissen Sie, CASE, UML und so weiter:

Die Verbindung zwischen einem Programmierer und seinem Code ist sehr kostspielig.

Wenn Sie dies tun, müssen Sie einen geeigneten Compiler / Interpreter erstellen. Codegeneratoren führen zu einem schrecklichen Workflow und einer schrecklichen Rückmeldung an den Programmierer (Fehlermeldungen und dergleichen).

Eine der großen Erkenntnisse von Domain Driven Design ist, dass Modelle im Code und nicht außerhalb des Codes vorliegen sollten.

Letztendlich lautet die Frage: Warum passen Ihre Modelle nicht in Code? Wenn Sie eine Embedded-Entwicklung durchführen und sich in C festsetzen oder Code für verschiedene Plattformen generieren müssen, ist die Codegenerierung möglicherweise die Kosten wert. Für alle anderen sind eine leistungsfähigere Programmiersprache und ein besseres Code-Design normalerweise besser als das Entwerfen des Codes in etwas anderem als dem Code.

Waquo
quelle
In Bezug auf DDD: Ich muss zugeben, dass ich DSELs wirklich mag. Ich verfolge (aus der Ferne) die Entwicklung des barrelfish-Betriebssystems ( barrelfish.org ) und sie haben Filet-o-Fish erstellt, ein Tool zum Erstellen von DSLs, und arbeiten dann direkt im Code auf einer höheren Abstraktionsebene.
Matthieu M.
6
  • Scheint wie ein riesiger Ärger für sehr wenig Nutzen.
  • Ich scheine immer mit Randfällen und seltsamen Dingen zu spielen, das magische Zeug scheint nie wirklich richtig zu funktionieren.
  • OO ist keine Silberkugel; Das Blobben einer Software-generierenden Methode auf OO macht es nicht silber.

Aber ich mag keine unternehmerischen Lösungen im Allgemeinen.

Paul Nathan
quelle
+1 für "Scheint wie ein riesiger Ärger für sehr wenig Nutzen."
Reeverb
5

Ich hatte die Diskussion und würde gerne MDA machen, aber der größte Nachteil ist die Toolunterstützung für den Moment. Ich verwende eine Ableitung von MDA, die ich gerne "Runtime Model Evaluation" nenne, aber dazu später mehr.

Die Nachteile von MDA sind, wie ich weiß:

  • Fehlende Refactoring-Unterstützung: Nehmen wir an, ich möchte die Entitäten meines Datenmodells mit MDA modellieren (typischer Anwendungsfall Nr. 1). Wenn ich mein Modell in einem UML-Diagramm habe und es ändere, ändert sich nichts an meinem Code (zumindest nicht an den generierten Klassen). Statt einer funktionierenden App mit besser benannten Attributen erhalte ich eine viele fehler muss ich manuell korrigieren.
  • Fehlende Debugging-Unterstützung: In der Regel werden Übersetzungen von Modell zu Code mithilfe einer Transformationssprache ausgeführt. Dies ist normalerweise kein Problem, aber wenn wir debuggen, sollten wir uns optimalerweise nicht um den generierten Code kümmern, und ein Debugger sollte in das Transformationsmodell einsteigen. Stattdessen springt es in den generierten Code ein, und wie wir alle wissen, sollten die Transformationen gut aussehen, nicht der generierte Code. Okey, wir können es schön ausdrucken, aber in einer optimalen Welt ist der generierte Code ein Compiler-Artefakt und sollte niemals in einem Editor für eine Debugsitzung geöffnet werden müssen (ich könnte damit leben, und dieses Argument ist ein bisschen theoretisch, aber es ist ein Grund gegen MDA)
  • Codierte Modelle sind einfach: In anderen Beispielen könnte das Modell einen Domänenaspekt modellieren, der dann in Code kompiliert wird. Ja, es ist MDA, aber die meisten MDA-Modelle sind nur hochentwickelte Konfigurationsdateien, die zur Laufzeit einfach gehandhabt werden können.
  • Transformationen sind schwer zu testen: Wenn Sie Transformationen in einer speziellen IDE verwenden, werden sie vom IDEs-Compiler ausgeführt. Die Transformationen müssen jedoch als Teil des Codes der Anwendung betrachtet werden und sollten als solche auch den Test- und Codeabdeckungsanforderungen der App unterliegen.

Was ich derzeit bevorzuge, ist "Runtime Model Evaluation" (wenn jemand einen akzeptierten Namen dafür kennt, klären Sie mich bitte auf). Meine Entitäten werden in gewöhnlichen Java-Klassen gespeichert, und alles, was ich zum "Modellieren" benötige, wird durch Anmerkungen erstellt, die ich beim Start der App gelesen habe. Es waren keine Transformationen erforderlich, es war nur ein bisschen schwierig, mein Metamodell richtig zu machen.

Alles andere erfolgt entweder mit Eigenschaftendateien oder XML für hierarchische Daten. Wenn Sie ein Modell haben, ist es immer hierarchisch, sodass Sie nichts modellieren können, was Sie nicht auch mit XML ausdrücken können. Und wenn Sie einen speziellen Modelleditor benötigen, den Sie wahrscheinlich auch schreiben müssen, können Sie auch einen Editor erstellen, der sogar zur Laufzeit der App funktioniert und die App konfigurierbarer macht als alles, was Sie modellieren könnten.

Daniel
quelle
Vielen Dank! Ich glaube, an Refactoring wird in mehreren Bereichen gearbeitet und MetaEdit kann das grafische Modell debuggen, aber ich habe in diesem Bereich nicht viele großartige Dinge gesehen.
KeesDijk
3

Ich habe das Gefühl, dass die meisten Leute, die Fred Brooks 'No Silver Bullet verwenden, um zu erklären, warum die Leute keine MDD machen, den Punkt verfehlen, den Brooks anführt. Die endgültige Schlussfolgerung ist, dass die tatsächliche, inhärente Komplexität bei der Entwicklung von Software niemals verschwinden wird und MDD dies daher nicht lösen wird.

Ein Grund, warum Brooks diese intrinsische Komplexität sogar diskutiert, besteht darin, sie mit der Zeit zu vergleichen, die wir normalerweise mit Sprachen, Bibliotheken und Werkzeugen verbringen, dh nicht mit der intrinsischen Komplexität des Problems, das wir zu lösen versuchen. Genau hier setzt MDD an: Den Fuzz beseitigen und eine maßgeschneiderte Sprache, ein Modell oder einen anderen Formalismus entwickeln, um der tatsächlichen Komplexität gerecht zu werden.

Aus dieser Perspektive ist No Silver Bullet ein ausgezeichneter Grund, in MDD zu investieren. Wenn da nicht das Problem wäre, von dem ich glaube, dass es die Akzeptanz von MDD behindert: Die tatsächliche Entwicklung einer modellgetriebenen Umgebung, die es Ihnen ermöglicht, sich vollständig auf die inhärente Komplexität des Problems zu konzentrieren, das Sie zu lösen versuchen, ist viel schwieriger als Lösen Sie das Problem einfach direkt in einer Allzwecksprache. Vor allem, weil die vorhandenen MDD-Werkzeuge äußerst komplex sind.

Vergleichen Sie es so: Es ist viel einfacher, ein Programm in C zu schreiben, als einen C-Compiler zu schreiben. Um eine MDD-Umgebung für andere Entwickler zu erstellen, müssen Sie nicht nur ein Problem lösen und sich mit der Cruft in einer Allzwecksprache befassen, sondern im Grunde ein Programm schreiben, das alle möglichen Cruft-bezogenen Probleme im Vorfeld des Problems löst. Das ist eine ziemliche Herausforderung.

Deckard
quelle
2

MDE und MDA gehen meines Wissens nicht ausreichend auf die Bedürfnisse der Embedded-Controller-Entwickler ein. Modelle können sicherlich zur Beschreibung eines Systems verwendet werden, aber ich glaube nicht, dass der eingebettete Entwickler bereit ist, dem Modell zu vertrauen, um den besten oder sogar richtigen Quellcode zu liefern.

Es gibt eine Reihe von Plug-Ins für Eclipse, mit denen ein Entwickler entweder das Modell zum Erstellen / Aktualisieren von Java-Code oder den Java-Code zum Erstellen / Aktualisieren des Modells verwenden kann. Dies scheint ein praktisches Werkzeug zu sein. Leider erfolgt meine gesamte Entwicklung in ANSI / ISO C, und es gibt keine mir bekannten Plug-Ins, mit denen ich dasselbe tun könnte.

Wie kann ein Entwickler das Modell außerdem anweisen, den Code als ereignisgesteuertes HSM oder ein anderes Entwurfsmuster über ein anderes Entwurfsmuster (oder Antimuster) zu implementieren? Kann das Modell das genau darstellen, wenn der Code manuell aktualisiert wird, um ein unbekanntes Entwurfsmuster zu verwenden?

Wie implementieren Sie die Funktionen, die nicht in ein Modell passen?

Oosterwal
quelle
Vielen Dank ! Ich habe CodeGeneration in Cambridge besucht ( codegeneration.net/cg2010 ) und die allgemeine Übereinstimmung war, dass die eingebettete Welt besonders für MDD geeignet ist. Auch ein Unternehmen in den Niederlanden, Thales ( thalesgroup.com ), macht große Fortschritte bei der Verwendung von MDD in Radarsystemen. Die generelle Funktionsweise der Systeme wird modelliert, die einzelnen Bausteine ​​werden für jede neue Hardware von Hand codiert. Dies beschleunigt das Ersetzen von Hardware erheblich.
KeesDijk
Das Modell sollte nichts über Entwurfsmuster wissen. Sie haben eine Software-Referenz-Software-Architektur, die Muster hat. Generatoren interpretieren das Modell und generieren anhand der Referenzsoftwarearchitektur. Wenn ein neues Muster verwendet werden muss, werden die Architektur und die Generatoren geändert.
KeesDijk
@KeesDijk: Wenn Sie angeben, dass die Embedded-Welt besonders für MDD geeignet ist, beziehen Sie sich auf Handy-Apps oder µController-Software, die in Autos und Haushaltsgeräten zu finden sind.
Oosterwal
Herzfrequenzmesser, Radarsysteme, Druckerhardware. Aber schauen Sie auf den Metaedit-Link und sehen Sie, was sie getan haben. Ich habe nur von µController SW gehört, der in Autos vorkommt, und dass er sehr komplex ist. Ich habe dort noch nie von MDD gehört, aber dass ich nichts davon gehört habe, ist keine gute Maßnahme :)
KeesDijk
Vor einiger Zeit hat ein Typ aus Matlab / Simulink versucht, uns den Code-Generator zu verkaufen. Zielgruppe sind Embedded-Controller. MISRA-C nicht gemacht und nicht zertifiziert, also ein bisschen traurig, das könnte sich geändert haben. Schauen Sie, es wurde C.
Tim Williscroft
2

Kurze Antwort… weil modellgetrieben oft mit der Codegenerierung zusammenhängt und Code zerbrechlich ist; Was wir brauchen, ist Code-Eliminierung und modellgetrieben ist sicherlich der richtige Weg.

Einige haben die Frage mit der Begründung zurückgewiesen, es gebe keinen goldenen Hammer und die Softwareentwicklung sei von Natur aus komplex.

Ich stimme ihnen voll und ganz zu, dass es keinen goldenen Hammer gibt, aber ich denke nicht, dass das Modellfahren eine Suche nach goldenen Hämmern oder silbernen Kugeln ist!

Ich möchte mit der Komplexität weiter gehen; Es gibt zwei Arten von Komplexität, die ich organische oder natürliche Komplexität nenne, Komplexität, die dem Geschäft und seinen Prozessen innewohnt, aber wir haben auch zeremonielle Komplexität.

Komplexität, die sich Tag für Tag in die Systemanweisungen einschleicht. Zeremonielle Komplexität - unnötige Komplexität - ergibt sich im Wesentlichen aus der unkontrollierten Verwirrung von technischem Code mit geschäftsorientiertem Code, aber auch aus dem Mangel an Struktur und Einheitlichkeit im System.

Heutzutage ist die gesamte Komplexität, die die Entwicklung von Informationssystemen verfolgt und Versagen und Taille verursacht, eine zeremonielle Komplexität. Komplexität, die beseitigt werden kann.

Zeremonielle Komplexität ist Verschwendung, Verschwendung durch Code, Wert weniger, Änderung nachteiliger, unveränderlicher Code; Code, der auf ein Minimum reduziert werden muss.

Wie geht das? Einfach, schreibe es einfach nicht und erstelle es nicht!

Notwendiger, unveränderlicher technischer Code; Code, der zum Lesen / Schreiben, Anzeigen, Kommunizieren verwendet wird. Hier kommen Modelle ins Spiel, indem sie die logische Struktur von Daten beschreiben - ich würde relational hinzufügen -. Modelle können die allgemeine Handhabung von Standard-Lesen / Schreiben, -Anzeigen und -Kommunikation ermöglichen Daten.

Es ist wie bei einem Betriebssystem, Sie schreiben es nicht für jedes Projekt neu, das Sie verwenden. Was also benötigt wird, ist eine technische Engine, die unveränderliche Aspekte von Software in einem gegebenen Modell behandelt. Ich nenne es eine AaaS-Engine (Architecture as a Service).

Was unnötigen Code angeht, so ist es unnötiger Code und kann ihn auch ungeschrieben lassen.

Das hinterlässt uns den notwendigen, geschäftsorientierten Code, der geschrieben werden sollte, die erforderlichen geschäftsorientierten Daten, die entworfen und die erforderliche Benutzeroberfläche und Erfahrung, die entworfen und vorgestellt werden sollten.

Indem wir fragilen Code eliminieren, können wir Architecture as a Service als neues Paradigma für die Softwareentwicklung verstehen, das viel mehr auf Modellierung und Design als auf Code basiert.

Fredy
quelle
2

Ich glaube, dass es mehrere Gründe gibt, aber einer ist sicher, dass MDD nicht im Lehrplan der Universitäten enthalten ist. In der Regel ist der nächste Kurs ein Kurs, der das Modellieren lehrt, und dort bleiben die Modelle als Skizzen erhalten (keine Überprüfung, Codegenerierung, Debugging auf Modellebene). Dieser "Modellierungs" -Kurs führt häufig auch in UML ein, und die Schüler sind verwirrt, warum sie eine so große und komplexe Notation lernen sollten, wenn der Wert der erstellten Modelle niedrig ist.

Vergleichen Sie dies mit anderen Bereichen des Ingenieurwesens wie Embedded-Hardware-Entwicklern oder Steuerungsingenieuren, in denen die Schüler eine ganz andere Erfahrung machen. Mit Tools wie Simulink oder Labview können Schüler ein Modell zeichnen und dann den Code generieren oder zumindest in der Simulation ausführen.

In der Vergangenheit haben Universitäten Compiler und Parser unterrichtet, aber jetzt sollten sie lernen, wie man Generatoren herstellt, DSLs implementiert usw.

Juha-Pekka
quelle
danke für deinen Beitrag. Ich muss zustimmen und sehe in naher Zukunft keine Lösung.
KeesDijk
2

Modellgetriebene Entwicklung ist nicht sinnvoll, da es sich um einen Ansatz handelt, bei dem von oben nach unten modelliert wird. Es ist unmöglich, eine vollständig laufende Anwendung nur von einem Modell aus zu erstellen, und daher ist MDD unbrauchbar !!

Ich verwende UML nur auf einer höheren Abstraktionsebene, um das Grundgerüst meiner Anwendung zu erstellen. Ich meine, erstelle Pakete, Klassen usw. und beginne dann sofort mit dem Code in Java.

Ich fand, dass die Live-Synchronisation mit Tools wie Togethersoft, Omondo sehr nützlich war, als ich 2004 zum ersten Mal mit dem Modellieren anfing. Kürzlich hat Omondo eine neue Stufe eingeführt, bei der es sich um eine Art Zuordnung zwischen Java, Modell und Datenbank-ID handelt. Wirklich mächtig und es funktioniert gut in meinen Projekten.

Meine UML-Diagramme helfen mir jetzt, mein Projekt zu beschleunigen und sind nicht mehr unbrauchbar :-)

UML_GURU
quelle
1

MDD fügt dem Entwicklungsprozess einen weiteren Schritt hinzu. Dies ist ein Nachteil in Situationen, in denen es kein gutes Modell gibt und die erste unvorhersehbare oder fast kaputte Teillösung auf dem Markt möglicherweise die meisten Murmeln gewinnt.

hotpaw2
quelle
1

Ausführbare Geschäftsprozessmodelle zu haben, war ein Grausamkeit. Theoretisch würden Sie dafür überhaupt keine Programmierer benötigen. Die Praxis zeigt, dass es mit MDE genauso kompliziert ist, ein tatsächliches Modell zum Laufen zu bringen, wie Code zu schreiben.

Ich würde sagen, für erfahrene Entwickler wäre es viel einfacher, aus UML generierte Klassen auszufüllen, als sich zum Beispiel mit ExecutableUML zu beschäftigen. Andererseits benötigen Sie für ExecutableUML ein beträchtliches Maß an Informatikkenntnissen, sodass Sie sich nicht darauf verlassen können, dass der Geschäftsführer diese Kenntnisse selbst erstellt. Theoretisch würde er nur fertige Blöcke (Klassen) kombinieren, aber eigentlich ist der "Klebstoff" das, was Probleme verursacht.

Der Nutzen von MDE ist auch auf Systeme beschränkt, die häufig wiederverwendet werden.

vartec
quelle
1

MBSE - Model Based Software Engineering ist der zutreffendere Begriff.

MBSE stellt die Frage nach den verschiedenen Tools, bei denen es sich um effektive Punktlösungen handelt, und erfordert einen anderen Projektworkflow. Die DSML (Domain Specific Modeling Language) muss auf der Abstraktionsebene sein, die erforderlich ist, um die Überprüfungsanforderungen effektiv mit den Stakeholdern zu kommunizieren. Dann müssen Sie das Modell durch immer höhere Verfeinerungsstufen transformieren, um schließlich Code zu generieren.

Wenn Sie die DSML- und Transformations- / Generierungsprozesse vollständig und korrekt implementiert haben, ist die Generierung von Artefakten sehr kostengünstig. Aber bis Sie dieses Stadium des debuggten Werkzeugs erreichen, ist es sehr schmerzhaft.

Die meisten Erfolgsgeschichten für MDD liegen im Bereich Product Line Engineering (PLE), bei dem eine Reihe ähnlicher Produkte mit etablierten Werkzeugen generiert werden. Natürlich sind viele der Java-Codegeneratoren wirklich vereinfachte Versionen von MDD. Ein bisschen XML rein und generierter Code raus.

CyberFonic
quelle
0

Sie schrieben:

Ich weiß auch, dass es viele Probleme gibt ... Projekte, die einfach nicht für die modellgetriebene Entwicklung geeignet sind (nicht genügend Wiederholungen)

Wenn sich Ihr Code wiederholt, haben Sie entweder eine schlechte Programmiersprache gewählt oder verwenden sie schlecht. Bei besseren Sprachen ist keine Wiederholung erforderlich. Betrachten Sie die Ruby Active Record-Bibliothek. Datenbanktabellen werden durch Schreiben von Migrationen erstellt. Es ist nicht erforderlich, die Schemadefinition an einer anderen Stelle zu wiederholen. Sie müssen keine Klasse mit Datenelementen definieren, die den Tabellenspalten entsprechen. Eine einzelne Codezeile verbindet eine Klasse mit einer Tabelle.

Ich betrachte die modellgetriebene Entwicklung als eine komplexe und ineffiziente Lösung für schwache Programmiersprachen.

Kevin Cline
quelle
1
Ich denke, wir sprechen über verschiedene Arten von Wiederholungen. Sie sprechen von der Wiederholung innerhalb einer Software, ich spreche von der Erstellung mehrerer ähnlicher Software-Komponenten, die beispielsweise dieselbe Software-Architektur aufweisen, jedoch unterschiedliche Funktionen aufweisen. Die Funktionalität wird modelliert und die Architektur generiert. Danke für die Antwort.
KeesDijk
@ Kees: Was meinst du mit "Architektur"? Wenn es sich um Code handelt, könnte ich die Wiederholung ausklammern und nur die Architektur instanziieren, indem ich die Dinge spezifiziere, die für jede Instanziierung spezifisch sind. Mit einer guten Sprache kann JEDE Wiederholung ausgeschlossen werden.
Kevin Cline
Es gibt keine guten oder schlechten Programmiersprachen, nur gute oder schlechte Entwickler. Solche Beispiele können mit jedem Webframework erstellt werden. Welche MDA / MDD / etc. Die Lösung besteht darin, ein Modell zu verwalten, sodass die Generierung mehrerer Komponenten wie Datenbank, Controller, Ansichten, Dienste usw. automatisch erfolgen kann. Idealerweise sollte das Modell sprach- und rahmenunabhängig sein (unter Berücksichtigung der OO-Sprachen), also jedes Modell könnte nach Rails, Spring, Zend, etc. exportiert werden
Cenobyte321