Heim

Diskussion:Model Driven Architecture

Inhaltsverzeichnis

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?

Welches sind die Teile eines Modells?

Herausforderungen

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


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

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

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 (Der vorstehende, nicht signierte Beitrag stammt von 134.155.22.101 (Diskussion • Beiträge) 19:48, 8. Feb. 2007 )