Was genau ist modellgetriebenes Software Engineering (MDSE)?

Ich bin heute auf infoq auf das accronym MDSE gestoßen , und die Informationen, die ich finden konnte, waren ziemlich unklar, und die Beschreibung war voller Schlagworte:

Bei MDSE geht es darum, Softwareentwicklern die Möglichkeit zu geben, auf einer Abstraktionsebene zu arbeiten, auf der Anforderungen, Architektur- und Entwurfsinformationen maximal geordnet (in Bezug auf die Informationsentropie) und erhalten bleiben. (Nennen Sie dies das "Design-Arbeitsprodukt"). Darüber hinaus sollte MDSE den Ingenieuren die Möglichkeit geben, ihre Entwürfe in erster Linie anhand ihres "Entwurfsarbeitsprodukts" zu überprüfen und zu validieren.

Und anscheinend macht es jeder: (wieder aus dem Artikel)

Wir stehen am Beginn des MDSE-Zeitalters. In den nächsten 5 bis 10 Jahren werden wir eine signifikante Verschiebung in Richtung MDSE erleben, insofern ich glaube, dass bis zum Ende dieses Zeitraums vielleicht 60 bis 80% der Software mit modellbasierten Techniken entworfen werden.

Ich hätte gerne eine konkrete, schlagwortfreie Beschreibung von MDSE. Zeichnet es UML-Boxen und generiert damit Code, wie sie es in den 90ern mit Rational Rose getan haben?

(Wenn jemand ein Beispiel für Software hat, die mit diesen Techniken erstellt wurde, würde ich mir wirklich ein konkretes Beispiel wünschen).

"Model Driven Software Engineering (MDSE)" ist das Marketingversprechen der Software-Tool-Hersteller, dass "bald" wesentliche Teile der Software aus Softwaremodellen generiert werden können.

Robert Howe, der Interviewpartner in dem Artikel, auf den Sie sich beziehen , ist ein Werkzeughersteller ( Einzelheiten siehe http://www.verum.com/ ).

Aber gegen die Versprechen der Werkzeughersteller ist mdse noch nicht zum Mainstream geworden.

Das hybris Internet-Shop-System ist ein funktionierendes Beispiel für "MDSE": Sie als Softwareentwickler verwalten XML-Modelldateien ("* -items.xml") und Codegeneratoren / Interpreter generieren DB-Modell / Java-Code für Persistenz / Guis heraus. Wenn Sie ein zusätzliches Attribut benötigen, fügen Sie es einfach dem XML-Modell hinzu. Nachdem der Generator / Interpreter seine Arbeit erledigt hat, können Sie das Attribut verwenden, um die Geschäftslogik zu implementieren.

IMHO " modellgetrieben " ist eine große Übertreibung, insbesondere in Verbindung mit Schlagworten wie "Design" oder "Software Engineering" (anstelle von "Entwicklung"). Es wurde wahrscheinlich von einigen Leuten erfunden, die das Missverständnis "Software-Design" haben, indem sie einige meist grafische Modelle mit UML zeichnen, wie ein Architekt einen Entwurf für ein Haus zeichnet, und "Codierung" ist wie das Verlegen der Steine ​​für das Haus. nach der Blaupause. (Ich hoffe, ich muss hier nicht erklären, warum dies falsch ist. Wenn Sie eine andere Meinung haben, lesen Sie bitte zuerst "Code as Design" von Jack Reeves, bevor Sie mich ablehnen.)

Dies ist ein großartiges mentales Modell für diejenigen, die sich "Architekten", "Geschäftsanalysten", "Designer", "Software-Ingenieure" nennen, die fünf Jahre Informatik studiert haben, aber nur ein halbes Jahr echte Programmiererfahrung (maximal) ) und suchen nun einen Job in der Softwareindustrie, der das "Entwerfen von Software" ohne Codierung umfasst. Ich denke, dies ist der wahre Grund, warum diese "modellgetriebenen" Schlagworte so beliebt sind.

Versteh mich nicht falsch, ich bin ein großer Fan von Modellen und Codegeneratoren, um die Notwendigkeit zu reduzieren, Boilerplate-Code manuell zu schreiben. In einigen eingeschränkten Bereichen wie beispielsweise Datenbanken können (Daten-) Modelle in der Tat ein gutes Instrument für die Kommunikation mit Domänenpersonen sein. Das Skizzieren des Datenflusses zwischen Komponenten nach Modellen ist meiner Meinung nach eine der wichtigsten Techniken, um Struktur in ein Softwaresystem zu bringen (leider haben die UML-Leute vergessen , Datenflussdiagramme in ihre Notation aufzunehmen; stattdessen haben sie eine Reihe redundanter, unnötiger Dinge hinzugefügt was in der Praxis niemand benutzt).

Aber ich würde dies " modellunterstützte Softwareentwicklung" nennen, nicht " modellgetriebenes Software-Engineering", was hoffentlich klar macht, dass die Modellierung nur die Hauptaktivitäten in der Entwicklung unterstützt, anstatt die Hauptaktivität selbst zu sein.

Das erinnert mich sehr an Fat-Modelle, Skinny-Controller- Konzept.
Die Hauptidee dieses Konzepts besteht darin, so viel Geschäftslogik wie möglich in das Modell zu integrieren und die Steuerung und die Ansicht sehr einfach zu halten.
Persönlich finde ich das eine sehr interessante Idee, obwohl ich keine Chance hatte, sie zu nutzen.
Überraschenderweise sprechen 8 von 10 Top-Links in der Google-Suche dagegen.
Wenn Sie sich ein Modell jedoch nicht als einzelne Klasse, sondern als Fassade mehrerer interner Klassen vorstellen, ist es durchaus sinnvoll, die Geschäftslogik im Modell beizubehalten.