Diskussion:Modellgetriebene Softwareentwicklung

Modellbsierte Softwareentwicklung

Modellbasierte Softwareentwicklung ist auf Modellgetriebene Softwareentwicklung. Das sind aber verschiedene Dinge. Siehe hier: bis.informatik.uni-leipzig.de/de/Lehre/0607/WS/MDIE/files?get=20070115_driven_based_oriented_jaehnichen_ep.pdf Weiß jemand, wie ich das ändern kann? (nicht signierter Beitrag von 217.194.34.103 (Diskussion | Beiträge) 10:34, 16. Jun. 2009 (CEST))

Tja, das ist irgendeine Werbeschrift, vielleicht ein PDF --Eva K. ^Post 13:11, 16. Mai 2006 (CEST)

Man sollte nicht einfach irgendwelche Behauptungen aufstellen. Dieser Text erklärt klar und deutlich die Bedeutung und den Nutzen von MDD.

Die Aussage "...englische Begriff Model Driven Development (MDD) wurde von der OMG markenrechtlich geschütz..." ist m. E. nicht zutreffend. Zumindest taucht er bei den OMG-Trademarks nicht auf (siehe OMG Trademarks). --Horron 00:18, 13. Dez. 2009 (CET)

Nachtrag: Offensichtlich hat die OMG das Recht an dem Begriff MDD bessesen, dieses aber 2004 wieder freigegeben (siehe: USPTO)--Horron 22:32, 28. Dez. 2009 (CET)

Die Aussage "Dabei werden domänenspezifische Sprachen (englisch Domain-Specific Languages, kurz DSL) zusammen mit entsprechenden Codegeneratoren und Interpretern eingesetzt" ist so nicht richtig, da bei MDSD keinesfalls nur DSL eingesetzt werden - wie man allein schon bei den unten aufgeführten Tools sieht. Das stand vor nicht allzulanger Zeit auch noch richtig im Beitrag. Aber an dem Artikel wird in letzter Zeit sowieso mit relativ viel Unkenngtnis rumgebastelt. (nicht signierter Beitrag von 91.34.170.195 (Diskussion) 02:44, 2. Jul 2010 (CEST))

Definition nicht ganz korrekt

Der Begriff der Modellgetriebenen Softwareentwicklung verwendet nicht die Konzepte der MDA. Damit sind Begriffe wie PIM und PSM usw fehl am Platz! Hier würde ich eher auf Metamodelle und Domain Specific Languages (DSL) verweisen und die Besonderheit der Modell-Transformation (vllt. im Vergleich zur MDA) behandeln..

Weiterhin sollte das Buch von Thomas Stahl und Markus Völter weiterhelfen (ISBN: 3-89864-310-7)

Grüße swm

MDD <=> MDSD

nach Voelter/Stahl: MDSD zielt präziser auf die Domäne der Software-Entwicklung <=> MDD suggeriert eine allgemeinere Bedeutung Vorschlag: Aenderung in MDSD (und kurze Erklaerung)

MDA, MDD, MDE, MDSD, ...

Es sollte eine klare Abgrenzung der Begriffe voneinander geben. Die Artikel zu MDA und MDSD differenzieren zu wenig. Warum finden sich im MDSD-Artikel Begriffe wie PIM und PSM? Andererseits wird im MDA (im zugehörigen Lemma) als allgemeines Vorgehensmodell beschrieben. MDA ist jedoch eine konkrete Ausprägung der OMG zur MDSD. (quellen: Voelter/Stahl: MDSD, Greenfield/Short: Software Factories, ...) Weiterhin erfährt man bei der englischen Wikipedia im Lemma MDE, dass MDD und MDA Marken der OMG sind (mit Quelle). -- Gast (nicht signierter Beitrag von 134.155.22.101 (Diskussion) 18:36, 8. Feb. 2007)

Ich hab diese Abgrenzung jetzt vorgenommen--Ma-Lik ? +/- 13:49, 8. Feb. 2008 (CET)

MDSD, MDD, MDSE und MDE sind synoyme Begriffe, wobei in Deutschland inzwischen meist von MDSD gesprochen wird und in den USA häufig MDE zu lesen ist. Die von der OMG definierte MDA ist eine Speziallisierung der MDSD. --Horron 00:59, 13. Dez. 2009 (CET)

Nachteile/Einschränkungen des MDD bitte ergänzen

Die unten erwähnten Punkte sollten im Artikel ergänzt werden, da sonst in der Tat der Eindruck einer werbenden Darstellung entsteht. In der Praxis bietet MDA an verschiedenen Stellen des Entwicklungsprozesses durchaus Vorteile, jedoch gelten dabei unbedingt die unten erwähnten Einschränkungen. Die Angaben zur Produktivitätssteigerung lassen sich in der Praxis bisher nicht verifizieren.

1.) Es ist fraglich ob das Versprechen der Beschleunigung von Software Entwicklung eingehalten werden kann. Wie Brooks bereits 1986 beschreibt, gibt es nur einen beschränkten Rahmen die Produktivität von Programmieren zu erhöhen. Er unterscheidet in unbeabsichtigter Komplexität, und essentieller Komplexität von Software, und schliesst dass erstere durch den Einsatz verschiedener Konzepte und Werkzeuge reduziert werden kann, während die essentielle Komplexität von Software erhalten bleibt.

siehe "No Silver Bullet - essence and accident in software Engineering", Brooks, F. P., Proceedings of the IFIP Tenth World Computing Conference, pp. 1069-1076, 1986

2.) Weiter muss das Versprechen von MDD Tool Advokaten kritisch hinterfragt werden, das mit der Hilfe von MDD Tools Software per Knopfdruck hergestellt werden kann. Ein guter Designer von Software baut sein Wissen auf einem breiten Fundament von Gebrauchsmustern (patterns) und ihrer Anwendbarkeit. Es muss bezweifelt werden das ein Designer durch die Verwendung von vollständigem MDD genug Wissen über Patterns erlangt, um diese effektiv und richtig einzusetzen. Ein guter Designer benötigt nur einen Teil dieser Werkzeuge (zur visuellen Kommunikation von Lösungen), und ein schlechter Designer wird durch die Verwendung keine besseren Designs erstellen.

siehe "Applying UML and Patterns", C. Larman , Addison Wesley, 2004

3.) MDA/MDD kann mangelndes Wissen um Gebrauchsmuster und Software Engeneering Erfahrung nicht kompensieren.

4.) Die Verwendung von generiertem Code in individual Software Lösungen widerspricht vielen Best Practice Regeln.

   - Lesbarkeit von Code
   - Verifizierbarkeit des Code
   - Wartbarkeit

-- Rawshark 15:22, 8. Feb. 2008 (CET)

Anmerkungen zu : Nachteile/Einschränkungen des MDD bitte ergänzen

Zu 1) Essentielle Komplexität schliesst ja nur die "fachliche Komplexität" ein. Der Rest ist "unbeabsichtigter Komplexität". Das schliesst z.B. den Lösungsraum (Programmiersprachen, Plattformen usw. zu tun) mit ein. Ich denke es ist unstrittig, dass man Produktivität durch bessere Werkzeuge erhöhen kann. Dazu gehören Programmiersprachen, IDEs aber auch alle anderen Dinge aus unserem "Werkzeugkoffer" (u.a. DSLs und Codegeneratoren). Falsch eingesetzt kann es natürlich auch den Aufwand und die Komplexität erhöhen. Bei MDSD geht es darum zu zeigen, wie man diese Technologien sinnvoll einsetzt.

Zu 2) Solche Versprechen sind selbstverständlich unsinn und kontraproduktiv. Das hat aber nichts mit MDSD oder Codegenerierung zu tun, sondern damit dass diese Leute schlicht MDSD nicht verstanden haben. Ein wichtiger Faktor bei MDSD ist, dass der Softwaredesigner selbst die DSLs und den Generator entwirft. Um das vernünftig machen zu können muss er/sie die Zielplattform (inkl. Frameworks, Idiome und Patterns) sehr gut kennen. Das ist kein Nachteil oder eine Einschränkung, sondern eine Selbstverständlichkeit. Irgendwo muss das Wissen ja her kommen.

Zu 3) Klar, ist was dran (siehe 2). Der Punkt ist, dass nicht unbedingt *jeder* im Projekt genau verstanden haben muss, warum die einzelnen Architekturkonzepte so sind wie sie sind, denn es gibt eine höhere Abstraktion, die zwar verstanden sein muss aber eben nicht mehr so komplex, viel lesbarer und vor allem nicht redundant ist. Das Wissen Weniger (das unbedingt vorhanden sein muss!) kann formalisiert werden und von anderen Widerverwendet werden. Im Prinzip ist das genau wie bei der Entwicklung von Bibliotheken und Frameworks: Nicht jeder der ein Framework wie Hibernate verwendet ist auch selbst in der Lage so etwas zu entwickeln. Trotzdem kann er es verwenden, aber sinnvoll nur so lange, wie er/sie die Konzepte der Schnittstelle verstanden hat. -> Abstraktion

Zu 4)

• Lesbarkeit von Code*

Generierter Code kann genauso lesbar oder unlesbar wie manuell geschriebener Code sein, das liegt nur am Generator. In der Regel ist generierter Code sogar lesbarer, da er symetrischer ist - Muster stechen klarer hervor.

• Verifizierbarkeit des Code*

(Falls damit testen gemeint ist) Dies ist genauso möglich und sinnvoll wie mit manuellem Code. Der Unterschied (Vorteil!) ist, dass es bei generiertem Code reicht jedes Konzept einmal exemplarisch zu testen. Weiterhin fällt fehlerhafter Code schneller auf, weil der selbe Fehler an allen Stellen generiert wird.

• Wartbarkeit*

Warum ist generierter Code nicht wartbar? Generierter Code ist natürlich viel wartbarer, da ich die ganzen redundanten Stellen generalisiert hab und nur an einer Stelle definiert habe (entweder im Generator oder im Modell). D.h. Dinge lassen sich leicht und schnell ändern (eine Stelle).

-- Benutzer:SvenEfftinge 20:30, 13. Juni 2008 (CET)

Vorgehensmodell

Ich finde "Ansatz" und "Vorgensmodell" passt nicht so gut, weil diese Begriffe suggerieren, dass es sich um eine neue, ganzheitliche Art handelt Software zu entwickeln. Das stimmt so nicht (jedenfalls sit das nicht die Sicht der Authoren des enstprechenden Buches (Stahl et.al.)). Vielmehr drfeht es sich bei MDSD um den Einsatz von DSLs und Generatoren/Interpretern und welche Auswirkungen diese Techniken auf die anderen Aspekte eines Softwareentwicklungsprojektes hat.

-- SvenEfftinge 11:01, 16. Jun. 2008 (CEST)

Also Vorgehensmodell ist meine ich sogar laut Stahl et.al. (finde die Seite grade nicht wieder) verkehrt in soweit stimme ich dir zu. Allerdings kann hier wohl kaum Modellgetriebene Softwareentwicklung vermittelt eine Sammlung von Best Practices die mit agilen Anzätzen... einen maßgeschneiderten Entwicklungsprozess anbieten(s.7) stehen, da das meiner Meinung nach eine reine Buchbesprechung wäre und nicht weit genug führt. Wie wäre es mit Softwareentwicklungsansatz oder Softwareentwicklungsmethode? Evtl sollte auch noch auf den Unterschied zwischen modellbasiert und modellgetrieben eingegangen werden.

Dann könnte hier auch noch auf Domain Specific Modeling eingegangen werden, da dieser Ansatz ja sehr ähnlich zum modellgetriebenen Ansatz nach Stahl ist (ich lese gerade das entsprechende Buch von Kelly et al Domain Specific Modeling. Enabling full Code Generation)--Ma-Lik ? +/- 14:23, 16. Jun. 2008 (CEST)

Der Begriff MDSD ist soweit ich weiß durch das Buch von Stahl definiert worden. Auf welche Auflage beziehst Du Dich (1. oder 2.)? Würde mich wundern, wenn das in der 2. Auflage noch so drin steht. Dort gibt es die Definition

MDSD ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen

Das trifft ziemlich genau was ich meinte, weil es den Fokus auf die Techniken legt und nicht so tut als wäre das irgendetwas ganzheitliches.

Was wäre Deiner Meinung nach der Unterschied zwischen modellbasiert und modellgetrieben?

Ja, man sollte gegen all die Dinge, die so ähnlich sind und doch anderes heißen abgrenzen (DSM, Software Factories, Generative Programming, MDA, etc.) SvenEfftinge 10:10, 17. Jun. 2008 (CEST)

Auf die Erste, aber soll das hier dann wirklich eine direkte Buchbesprechung werden? (Dann müsste das auch in der Einleitung geschrieben werden) Bzw wurde der Begriff von anderen Autoren mit anderen Definitionen aufgenommen? Für den erste Satz ist es sicherlich sinnvoll eine Quelle einzufügen, von daher wäre es sicherlich sinnvoll den Satz so zu übernehmen--Ma-Lik ? +/- 11:44, 17. Jun. 2008 (CEST)

Beispiele für integrierte MDD-Werkzeuge

Ich würde gerne die Liste der Werkzeuge aufräumen. Einige der gelisteten Tools sind "nur" UML Tools, haben meiner Meinung nach also mit MDSD nur peripher zu tun. Ich würde daher folgende Liste der Anforderungen für ein vollwertiges MDSD-Tool vorschlagen:

• kann mit flexiblen Metamodellen umgehen
• alternativ: unterstützt das UML Metamodell und kann durch UML Profile erweitert werden
• Anbindung an Code-Generatoren möglich durch XMI-Export oder EMF-Schnittstelle oder andere geeignete Möglichkeit, Modelle zu exportieren

Weiterhin wäre es sicherlich angebracht, die nicht mehr am Markt verfügbaren Tools entweder zu entfernen oder in eine Liste historischer Tools aufzunehmen.

Feedback? --PeterFriese 10:03, 17. Jun. 2008 (CEST)

Ja, finde ich auch.

Wobei ich bei den UML-Tools einfach sagen würde, dass man halt UML-Tools verwenden kann. Die Tools selber können dann auf der entsprechenden Seite aufgelistet werden.

Das gleiche gilt dann für Parsergeneratoren und XML parser. Alles Dinge, die man wiederverwenden kann, aber für sich keine MDSD Werkzuge sind. SvenEfftinge 10:10, 17. Jun. 2008 (CEST)

Ja, aber das sollte man dann auch so erwähnen. Aber es gibt ja UML-Werkzeug--Ma-Lik ? +/- 11:54, 17. Jun. 2008 (CEST)

Ich habe den Abschnitt etwas ergänzt, sortiert und geprüft ob es die Tools überhaupt noch gibt. Ich finde er enthält noch zu viele "rote" Links. Die Tools sind teilweise sehr speziell. Ich glaube nicht, dass in absehbarer Zukunft dafür Artikel erstellt werden. Ausserdem bin ich bei 3 Tools unsicher ob es überhaupt MDSD-Tools sind - das prüfe ich aber noch mal in den nächsten Tagen. -- Horron 19:00, 9. Dez. 2009 (CET)

Modellierung vs. Programmierung

Ich habe ein begriffliches Problem, einerseits innerhalb des Artikels, aber vermutlich auch mit der Terminologie des MDSD selbst:

Die Begriffe Modellierung und Programmierung werden im Rahmen von MDSD in einer bestimmten Weise verstanden, und zwar in einer Weise, die m. E. mit gängigen Interpretationen dieser Begriffe kollidiert:

Wenn aus dem bei MDSD als Modell bezeichneten Artefakt automatisiert Code erzeugt wird, dann ist dieses Artefakt nach gängiger Definition Quelltext, also Programm. Die automatisierte Erzeugung nennt man dann Compilierung, wobei die Quellsprache die Sprache des Modells und die Zielsprache die Sprache des erzeugten Codes ist. Der Begriff Modell wird daher bei MDSD in der Bedeutung "in einer höheren oder graphischen oder problemspezifischen oder domänenspezifischen Programmiersprache programmiert" verwendet: MDSD Modelle sind keine Modelle von Software, sondern sie sind die Software selbst. Durch den Austausch der Begriffe Programm, Programmieren, Compilieren durch die Begriffe Modell, Modellieren, Codeerzeugung wird der Eindruck erweckt, als ob die Tätigkeit der Programmierung nun automatisch erfolgen würde (als Botschaft kommt an: "der Code wird automatisch erzeugt, nicht mehr programmiert").

Es wäre m. E. für den Artikel zwecks Vermeidung von Verwirrung hilfreich, wenn die Begriffe Modell, Programm und Codeerzeugung, wie sie im Kontext von MDSD verwendet werden, definiert und den ansonsten gängigen Begriffen und Interpretationen gegenübergestellt würden.

Ich würde den Artikel gerne dahingehend erweitern, aber ich möchte sichergehen, dass ich mit meiner Auffassung nicht allein dastehe. -- DirkHerrmann 01:32, 2. Jan. 2010 (CET)

Hallo, ich finde deine Idee ganz gut. Letztendlich ist der Ansatz der MDSD im Kern ja nichts anderes, als durch den Einsatz von Programmiersprachen auf einem höheren Abstraktionslevel (Model), die Komplexität des Systems zu verringern. Ist diese Programmiersprache auch noch domänenspezifisch, trägt dies zu einer weiteren Verringerung der Komplexität bei (und Erleichtert die Kommunikation mit Domänenexperten). Ich fänd eine Ergänzung des Beitrags in diese Richtung gut. Da ich den Artikel gerade auch am Umbauen bin, wäre es gut wenn du dass in ein eigenes Kapitel packen könntest. --Horron 11:58, 3. Jan. 2010 (CET)

Hallo, auch wenn ich hier prinzipiell zustimme und die verwendeten Tools, nach meiner Meinung, keine wirklichen Neuerungen darstellen, sehe ich den Schwerpunkt in der MDSD in der Herangehensweise an eine Aufgabe bzw. in der Abstraktionsebene. Hier gab es auch schon früher sprachliche Unterscheidungen (Machienensprache -> Assembler -> Hochsprache). Einzuordnen ist MSDS hier eventuell in die Reihe der Programmierparadigmen und der damit verbundenen Methoden (vgl. objektorientierte Programmiersprachen). Hiernach währe der Codegenerator ggf. ein Transcompiler (siehe Compiler#Sonderformen), während die Entwicklungsmethode an sich durchaus eigene Namen rechtfertigt (vgl. Modul vs. Objekt bzw. Funktion vs. Methode). Ungeachtet dessen würde eine solche Gegenüberstellung, mit dem Hinweise auf die besondere Methode, gerade Einsteigern sehr helfen MDSD richtig einzuordnen. -- DocEmmet 14:49, 18. Okt. 2010 (CEST)

Unverständlich

Der ganze Artikel ist auch für Programmierer unverständlich. Wirkt so, als ob dass aus einem BWL-Buch kopiert wurde, wo MDD als DIE Lösung (schließlich wird dann ja z.B. in UML modelliert!) angepriesen wird. Der ganze Artikel gehört überarbeitet (nicht signierter Beitrag von 77.10.196.111 (Diskussion) 11:42, 14. Okt. 2016 (CEST))