Diskussion:Modellgetriebene Softwareentwicklung

message: 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)
thread_title:  Modellbsierte Softwareentwicklung 

message: 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 
:Ich hab diese Abgrenzung jetzt vorgenommen--Ma-Lik  ?  +/- 13:49, 8. Feb. 2008 (CET)
thread_title:  MDA, MDD, MDE, MDSD, ... 

message: 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)
thread_title:  Nachteile/Einschränkungen des MDD bitte ergänzen 

message: 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)
thread_title:  Anmerkungen zu : Nachteile/Einschränkungen des MDD bitte ergänzen 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Modellierung vs. Programmierung 

message: 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)
thread_title:  Unverständlich