Diskussion:Modellgetriebene Architektur

Quellenangabe und Genehmigung des Ersttextes

Der vorliegende Text wurde von Dipl.-Inform. Wolfgang Neuhaus (itemis GmbH & Co. KG) und Dipl.-Inform. Thomas Stahl (b und m AG) erstellt und erschien im September 2003 im JavaMagazin. Die Veröffentlichung dieses Textes ist genehmigt. Eingestellt wurde der Text von Wolfgang Neuhaus. Für Rückfragen wenden Sie sich bitte an wolfgang.neuhaus@itemis.de, thomas.stahl@bmiag.de oder sebastian.meyen@softwaresupport.de.

Offene Fragen

Zur Entstehung der Konzepte der MDA

Kann jemand beschreiben woher die Idee der MDA stammt?

• MDA ist die konkrete Ausprägung der OMG zur MDSD -- Gast

Herausforderungen

Was gab es bisher für Hindernisse bei der Anwendung?

• die MDA gilt allgemein als komplex und aufwändig in der Anwendung
• beliebter sind derzeit schlanke Ansätze mit Domain-specific Languages (DSLs), d.h. anwendungsspezifische Modellierungsmodelle (SysML, BPMN etc.)

Abgrenzung zu 4GL-Sprachen

Wie unterscheidet sich die Idee von den 4GL-Sprachen, die ja ähnliches versuchten? Ist der Unterschied, dass jetzt UML und die OOP-Programmierung genutzt wird ?

Die zwei angeführten Begründungen für MDA

• Steigerung der Programmierereffizienz
• Bessere Wartbarkeit

sind auf jeden Fall dieselben wie für die Viertgenerationssprachen.

Haben wir hier den Nachvollzug dieser Ideen für die Generation der OOP-Programmierer vorliegen?

HannesH 10:20, 2. Nov 2004 (CET)

Revisionsanforderungen

Inhaltliche Änderungen

Gliederung, Aufbau des Artikels

Ich würde es sehr begrüßen, wenn eine Einleitung erst einmal, möglichst leicht verständlich, erklären würde, was dieses Ding "MDA" überhaupt ist und wozu es im wesentlichen dient. Als Zielleser sehe ich jemanden an, der das erste Mal mit diesem Thema bzw. Begriff konfrontiert ist. (Normalerweise mache ich so etwas gleich selber, als andere Leute zur Arbeit anzuhalten, aber leider reichen meine Kenntnisse zu diesem Thema nicht aus.) - Vielen Dank im voraus --michaelsy 18:40, 14. Dez 2005 (CET)

Abgrenzung: MDA und CASE-Ansätze

Im Artikel steht MDA ist kein CASE-Ansatz. Begründet wird das damit, dass a) bei klassischen CASE-Tools häufig sowohl Metamodell wie auch Transformation fix sind b) CASE-Tools in der Regel proprietäre Modellierungssprachen benutzen c) Interoperabilität fehlt d) Modellierungssprache und der generierte Anteil sich nicht anpassen lassen.

Die vier Punkte sind Eigenschaften, die bei CASE-Tools häufig zutreffen. Es sind aber Eigenschaften die nicht den Kern der CASE-Idee berühren, sondern es handelt sich um (wohl technologiebedinge) Einschränkungen oder Mängel. Daher erscheint es mir unzutreffend zu formulieren MDA ist kein CASE-Ansatz. Die Formulierung MDA erweitert den klassischen CASE-Ansatz ist aber auch nur sub-optimal (was ist denn der "klassische CASE-Ansatz"?). Vielleicht trifft es der Satz MDA erweitert die CASE-Idee der Codegenerierung aus Modellen besser.

Sinnvoll wäre vielleicht auch, zunächst den relativen allgemein Begriff CASE zu definieren (der bisherige deutsche Wikipedia-Eintrag ist auch nicht besonders gut). Sind damit wirklich nur die Ansätze gemeint, Software mit Hilfe von Modellen zu beschreiben, oder umfasst "Computer Aided Software Engineering" nicht jegliche Ansätze, werkzeugunterstützt Ordnung und Struktur in Software zu bekommen? In diesem Sinne sind auch GUI-Builder und Versionsverwaltungssysteme CASE-Tools.

HannesH 10:56, 2. Nov 2004 (CET)

Dieser Artikel ist ungenau und übergeht wesentliche Konzepte, wie z.B. die Viewpoints der MDA. Weiterhin ist die Empfehlung zum Praxiseinsatz unrichtig. Es gibt inzwischen Standards, die MDA erfolgreich einsetzen und ihre Praxistauglichkeit durch Referenzimplementierungen unter Beweis gestellt haben (z.B. PLM Services der OMG).

Von mir aus dem Text hier her verschoben. Ich aber nicht der Author, des Textes oben! -- Sparti 04:08, 29. Mai 2005 (CEST)

Die Tätigkeitsbeispiele der OMG stehen unter OMG, wo sie auch hingehören. Habe sie deshalb dort erweitert und hier herausgenommen. --194.231.193.224 09:35, 8. Sep 2005 (CEST)

Der Abschnitt Vor- und Nachteile sollte überarbeitet werden. Die folgende Aussage Nachteilig ist aber der sehr hohe Abstraktionsgrad, der den Softwareentwicklern abverlangt wird. Selbst ausgebildete Wirtschaftsinformatiker, denen Softwareentwicklung an sich leicht fällt, sind hiermit oftmals überfordert. ist ein Hohn von allen studierten Softwareentwicklern. Sollte ein Softwareentwickler nicht fähig sein, mit einem hohen Abstraktionsgrad zu recht zukommen, sollte er diesen Beruf nicht ausüben. [/gekürzt/] Abstraktion ist aber ein wesentlicher Faktor bei neuen Programmiermethoden, Bei höherem Abstraktionsgrad ist der Einarbeitungsaufwand ungleich höher, als bei 0815 Sprachen. Wenn die Abstraktion einen Grad erreicht, der von einem einzelnen Menschen nur noch nach 15 Jahren Studium gemeistert werden kann, ist doch was faul. Relevant meiner Meinung nach ist der Faktor (Entwicklungsgewinn / Abstraktionsgrad).

Der MDA-Ansatz eignet sich folglich insbesondere dann, wenn die Aufgabenstellung vergleichsweise komplex ist und bereits zu Projektbeginn vollständig und endgültig fixiert werden kann. Jeder Softwareentwickler/architekt weiß, dass es so etwas nicht gibt. Demnach wäre der MDA-Ansatz nie einsetzbar! Welche Kompetenz besitzt der Autor dieser Sätze? <- ( Aus A->B , gilt NICHT automatisch B->A , lern erstmal Mathe Junge)

Folgende Änderungen sind nötig:

1. Sachliche, unbewertete Darlegung der MDA und deren Ziele
2. Relativierung der persönlichen Meinungen einzelner Autoren
3. Fundierte Herausarbeitung von kritischen Aspekten

Kritik: Darstellungen zum Modellbegriff der OMG im Rahmen der MDA

Dieser Artikel ist leider sehr schwach -- einerseits verständlich, da die 'MDA' gg. noch eher eine lose Vision ist (Stand 05/2006), anderseits unverständlich, da selbst die einfachsten Basiskonzepte unzutreffen beschrieben werden. Allein im Abschnitt Modell:

' MDA-Modelle werden in der Regel in UML definiert. '

Was heißt "in der Regel"? Die Revision des MDA-Guides geht eindeutig in die Richtung, die höhere Bedeutung der MOF für die MDA herauszustellen. Im Sinne der MDA ist ein Modell eine Instanz eines MOF-konformen Metamodells. Und damit: z.B. der UML.

' Aber auch klassische Programmiersprachen eignen sich als Modellierungssprachen. Ihre Programme sind MDA-Modelle. '

Dieses ist dann, siehe oben, unzutreffend.

' Nicht jede Sammlung von UML-Diagrammen stellt ein Modell im Sinn von MDA dar. '

Ein UML-Diagramm ist kein Modell, sondern eine Repräsentation eines 'Aspekts' eines Viewpoint( Model)s eines Modells.

' Der wichtigste Unterschied zwischen allgemeinen UML-Diagrammen (z.B. Analyse-Modellen) und MDA-Modellen liegt darin, dass die Bedeutung von MDA-Modellen formal definiert ist. '

Das trifft, siehe oben, auch auf Analyse-Modelle zu, wenn sie in MOF-konformen Modellierungssprache formuliert werden (siehe z.B. Business Modeling Standards der OMG) -- dieser Modell-Typus wurde in der 2003'er Fassung als CIM bezeichnet.

' Ein Generator muss genügend Information vorfinden, dass das MDA-Modell auf ein anderes Modell oder auf Sourcecode abgebildet bzw. transformiert werden kann. '

Und hier wird's nun richtig falsch ...

Formulierungen

Kritik an der Aussage in Vor- und Nachteile

Die Aussage

"Des Weiteren erfordert eine automatisierte Transformation eines Modells häufig eine wesentlich formalere Beschreibung, als dies für die Transformation durch einen Menschen erforderlich ist. Beispielsweise sei eine Klasse Person mit dem Attribut geborenAm gegeben. Ein Programmierer braucht keine besonders detaillierte Beschreibung, um die Funktion gibAlterInJahren zu implementieren. Für eine automatische Transformation (zu Quellcode oder in ein anderes Modell) muss jedoch eine genaue Spezifikation vorliegen."

ist falsch! Ich hoffe nicht das ein Programmierer ohne detailierte Spezifikation etwas umsetzt! Wenn eine Funktion gibAlterInJahren programmiert werden kann, so ist nach dem gleichen Prinzip auch eine formale Spezifikation möglich! (nicht signierter Beitrag von 141.89.226.149 (Diskussion) 16:46, 24. Nov. 2010 (CET))

In:Abschnitt "Model Driven Architecture (MDA) als OMG-Standard"

Hier wäre eine Ersetzung des Terminus der Codetransformation durch eine andere Begrifflichkeit wünschenswert; Codetransformation impliziert m.E. eine Quelltexttransformation, keine Modellsynthese/-kompilierung (oder Codeprojektion, sprich, eine Abbildung resp. Übrführung eines Modells in ein Quelltextartefakt).

Weitere Quellen

Als Empfehlung an Interessierte, die sich der weiteren Pflege dieser Seite widmen wollen, wurde ff. Referenzlink gegeben:

http://www.software-kompetenz.de/?5348

Die Seite des Virtuellen Software Engineering Kompetenztentrums bietet sehr umfassende Informationen zu diesem Thema (und weiteren Fragestellungen der Softwaretechnik und -entwicklung).

Inhaltliche Fehler - MDA Konzepte im Überblick

Gehört überarbeitet, hier wird konstant der Begriff Diagramm und der Begriff Modell verwechselt, die Darstellung so ist leider völlig falsch.

OMG-Spezifikation in Einleitung erwähnen

Es sollte direkt in der Einleitung erwähnt werden, dass es sich um eine offizielle Spezifikation der OMG handelt. Dies ist einer der wichtigsten Punkte an der MDA. Es handelt sich um einen (z.T. noch in der Entwicklung befindlichen) Industriestandard. Dies grenzt die MDA deutlich von der MDD/MDSD ab. -- J.Gottschling, 23.08.06

Abgrenzung zu MDSD

Mir fehlt in diesem Artikel die inhaltliche Trennung von MDSD und MDA. MDA ist eine konkrete Ausprägung der OMG zur MDSD, daher sollte dieses Lemma auch nur diesen Ansatz erläutern. Derzeit scheinen beide Begriffe vermischt betrachtet zu werden. -- Gast (nicht signierter Beitrag von 134.155.22.101 (Diskussion) 19:48, 8. Feb. 2007)

Begriffe

Was genau ist da mit "Plattform" gemeint? Die Beispiele geben darüber wenig Auskunft. (nicht signierter Beitrag von 81.173.201.225 (Diskussion | Beiträge) 13:19, 1. Apr. 2010 (CEST))

Ausdruck bzw. Abgrenzung der Modelle

Aus dem Abschnitt "Vorgehen": "Insbesondere durch das CIM und vor allem das PIM möchte man nicht nur Plattformunabhängigkeit erreichen, sondern auch Sprach- und Systemunabhängigkeit."

Warum jetzt insbesondere durch das CIM aber trotzdem vor allem das PIM? Ich denke im Allgemeinen sind die Modelle zunächst unabhängig von der Technik und werden Modell für Modell immer spezifischer und abhängiger von konkreten Techniken bzw. Technologien. Könnte ja auch sein, dass man da noch mal ein weiteres Modell dazwischen packt.

Neuer Formulierungsansatz: "Das CIM ist unabhängig von einer konkreten Sprache. Das PIM kann von einer konkreten Sprache abhängig sein, ist aber unabhängig von einer konkreten Plattform."

Ich bin mir aber noch nicht sicher, ob das so immer zutrifft. Was heißt in diesem Kontext Plattform? Das Betriebssystem? Die Ausführungsumgebung (z.B. JRE oder CLR, oder nativ). Ist damit immer dieselbe Abstraktionsebene gemeint? --217.6.182.193 09:49, 23. Mär. 2012 (CET)

Schreibweise des Titels

Die Schreibweise "Model Driven Architecture" im Titel entspricht weder den angelsächsischen noch den deutschen Regeln und ist auch nicht üblich. Im Angelsächsischen ist "Model-driven Architecture" korrekt (wie auch in der engl. Wikipedia getan) und im Deutschen sind Bindestriche nötig, also eingedeutscht "Model-driven-Architecture" bzw. übersetzt "Modellgetriebene Architektur". Ich favorisiere die engl. Fassung "Model-driven Architecture", da das die feststehende Benennung für den Ansatz der OMG ist. Gruß ossipro (Diskussion) 13:21, 26. Mär. 2014 (CET)