Model Driven Architecture (MDA)

[Reima Laaksonen]

Hallo,

hat jemand schon probiert, or bzw benutzt zur Zeit, ein sogenannte "architectural IDE" oder OMG's Model Driven Application (MDA)?

Ich evaluiere zur Zeit ArcStyler ( http://www.ArcStyler.com ) und finde es sehr interessant und die möglichkeiten gut. Am allermeisten gefällt mit die schnelligkeit, die es bietet.

Ich bin sehr interessiert an "real-life-experiencies" mit dieser Technologie (wie z.B. hier: http://www.theserverside.com/resources/articles/BausparenOnline/article.html ).

- Ray

[Sebastian Meyen]

Hallo,<BR> im nächsten Java Magazin (ab. Mitte August verfügbar) erscheint ein ausführlicher Schwerpunkt über MDA mit einer Reihe von Beiträgen.<BR>S. Meye

[Wolfgang Neuhaus]

Hallo,

als einer der Mitautoren des aktuellen MDA Schwerpunkts im Java Magazin stelle ich mich gerne als Diskussionspartner zur Verfügung. Wer persönlich mit mir in Kontakt treten möchte, kann dies per Mail tun: [email protected]

Praxiserfahrungen, wie du sie angesprochen hast, Ray, sind noch nicht in der Breite vorhanden. MDA ist ein aufkommender Trend. Allerdings sind bereits heute praktisch einsetzbare Lösungen vorhanden. Und mit der Ankündigung der b+m Informatik AG, dass ihr GeneratorFramework Open Source geht, steht ein echtes Profi-Werkzeug einer breiten Anwenderschaft zur Verfügung. Ich hoffe, dass diese Entwicklung die Bereitstellung vorgefertigter Anwendungsfamilien für bestimmte Architekturmuster fördern wird.

- Wolfgang Neuhau

[B. Lösel]

Hallo,

seltsam wenig Leute für so ein spannendes Thema ...

Die Vision ist bestechend: Sinnliches Malen auf dem Tablett-PC generiert eine Software - vorbei das kopflastige Tippen.

Berufmäßig beschäftige ich mich gerade mit der Erzeugung von Datenbank-Definition samt der JAVA-Zugriffsklassen aus UML. Dabei bin ich an viele Grenzen gestoßen, es sind halt so viele Parameter, dass für die volle Komplexität halt viele Worte nötig sind!

Allenfalls für Prototypen scheint mir MDA möglich.
Eher wird es eine Kombination geben: UML für den Überblick und das Grobe, eine Programmiersprache fürs Feine(von OCL halte ich nix). Jedenfalls werden wir professionell in diese Richtung gehen.

Es bleibt spannend, wie es sich schließlich entwickelt!

B. Lösel, [email protected]

[Carsten Robitzki]

Hallo,
<BR>es sind tatsaechlich erstaunlich wenig Beitraege zu dem Thema - aber das muss ja nicht so bleiben...
<P>Ich arbeite nun seit mehreren Jahren mit generativen Techniken im Sinne des MDA und kann deine Befuerchtungen, dass dieser Ansatz nur fuer Protoypen geeignet ist, nicht teilen. Sogar genau das Gegenteil ist der Fall (bei unserer Interpretation des MDA-Ansatzes - vgl. Artikelserie im Java-Magazin 9/2003 und 10/2003). Bei Neuentwicklungen auf neuen Plattformen sollte der Protoyp manuell implementiert werden, wobei der Prototyp saemtlich architekturelle Aspekte abdecken muss. Ist dieser getestet und die Architektur tragfaehig, dann koennen anhand des Prototypen architekturelle Muster identifiziert und die Designsprache (=UML-Profil) fuer das PIM bzw. die Transformationsschablonen abgeleitet werden. Und erst dann kann die Anwendung ja mit Hilfe dieser generativen Architektur (Designsprache, Transformationsschablonen, Laufzeitsystem) realisiert werden.
<P>In meinen bisherigen MDA-Projekten haben wir es immer geschafft, aus dem Klassenmodell das Datenbankschema zu 100% abzuleiten. Dennoch mag es Faelle geben, in denen es durchaus sinnvoll ist, Moeglichkeiten vorzusehen programmatisch am generierten Schema eingreifen zu koennen. Das gilt aber fuer das gesamte Generat. Aber hierfuer bieten die Generatoren immer Moeglichkeiten an - mit dem b+m GeneratorFramework lassen sich z.B. in den Schablonen geschuetzte Bereiche auszeichnen, die dann im generierten Code manuell gefuellt werden koennen und bei folgenden Generatorlaeufen erhalten bleiben.
<P>Das sinnliche Malen einer Software und per Knopfdruck eine lauffaehige Software zu produzieren (komplett ohne Tipparbeit) wird warscheinlich eine Vision bleiben (bis auf sehr wenige Ausnahmen), da es zwar technisch moeglich aber nicht sinnvoll ist. Auch wenn die Vorstellung nett ist, dass bald alle Softwarefirmen Malereibetriebe sind - dann werde ich trotz meiner zwei linken Haende doch noch zum Handwerker:-)
<P>Carsten Robitzki, [email protected]

[B. Lösel]

Hallo,

interessant, zuerst manuell und dann erst automatisch zuarbeiten - muss wohl mal die Artikel lesen.

Ich greif mal ein Beispiel heraus, um meinen Standpunkt klarer zu machen:

Im Modell besteht zwischen 2 Klassen eine Assoziation, sagen wir mal 1 zu n. Daraus leiten wir 2 gleichnamige Tabellen ab, soweit keine Probleme.

Aber die Assoziation? Wie bilde ich sie in der Datenbank ab?

Zunächst fällt die Wahl auf eine altbekannte relationale Datenbank, da auch im Jahr 2003 Sicherheit und Performance dort noch besser ist.

Für sichere, umbedingt konsistente Datenhaltung mache ich aus der Assoziation referenzielle Integrität.
Für schnelle und von Hand änderbare Datenhaltung mache ich einen View aus den 2 Tabellen (so funktioniert auch unsere Lösung).

Das ist nur ein Beispiel - es gibt immmer sehr viele Möglichkeiten, ein Modell in eine Applikation zu verwandeln.

Das ist quasi ein Naturgesetz, da das Modell IMMER einfacher als die Applikation sein muss (sonst wärst kein Modell, die Applikation "modelliert" ihrerseits die Wirklichkeit).

Performance und Bedienfreundlichkeit kann deshalb im Modell nicht berücktsicht werden, die jeweiligen technischen Kompromisse und Abwägungen sind zu kompliziert dafür.

Deshalb mein Schluss: MDA nur für Prototypen, da diese langsam und schlecht bedienbar sein dürfen.

Grüße, Burkhard Lösel [email protected]

[Frank Weinhold]

Hallo!

Ich verfolge seit Anfang des Jahres die Fachpresse und Literatur in Bezug auf MDA. Ich muß feststellen das sehr viele Beispiele sich auf J2EE beziehen. Als Plattform wird immer Middleware gewählt.
In meiner Diplomarbeit beschäftige ich mich damit funktionale Anforderungen so zu modellieren, das man diese auf eine Architektur von Softwarekomponenten übertragen kann.
Nichtfunktionale Anforderungen, wie Architektur, Struktur von Softwarekomponenten werden auf Basis eines Metamodells erzeugt.
Das meines Vorgehens ist es die Aufmerksamkeit des Entwickler voll auf die Realisierung der Geschäftslogik zu legen und Dinge von Kommunikationslogik (Corba,...) automatisch zu erzeugen (auf Modell und Quellcodeebene).

Ich denke das liegt im Sinne der MDA, oder

[Carsten Robitzki]

Hallo,

<BR>die meisten Beispiele zum Thema MDA basieren warscheinlich auf verteilten J2EE-Architekturen, da es
eine komplexe Architektur darstellt, von der gut abstrahiert werden kann und momentan sehr haeufig anzutreffen
ist. Das bedeutet natuerlich mit nichten, dass MDA nur mit J2EE funktioniert...
<P>Wie Frank ja richtig geschrieben hat ist der Ansatz von MDA, die Trennung zwischen funktionalen Aspekten
(modelliert im PIM) und der Ablaufplattform durchzusetzen. Das PIM soll und muss somit von technischen
Details, die sich durch die Plattform ergeben, abstrahieren.
<BR>Und jede Plattform bedingt spezifischen Infrastrukturcode, der mal groesser ausfaellt (wie z.B. bei EJB oder CORBA)
oder mal nur geringen Umfang hat. Und dieser zieht sich durch alle Schichten (z.B. Client, Serviceschicht, Entities,
Persistenzschicht) und sollte von jedem Entwickler gleich behandelt werden. Und hier behilft sich in der Regel der
Entwickler mit dem altbekannten Copy&Paste oder irgendwelchen kleinen Hilfsprogrammen um diesen schematischen Code
zu erzeugen. Und das zeigt doch schon, dass zumindest dieser Infrastrukturcode auch durch generative Techniken
erzeugt werden kann (und ich behaupte, es kann sogar noch mehr generiert werden) da er eben stark schematisch ist.
<P>Natuerlich wird es immer Problemstellungen (auch innerhalb eines groesseren Softwaresystems) geben, die nach einer
sehr spezifischen Loesung schreien und eben nicht zu den 90%-Standardfaellen gehoeren. Aber generative Techniken
und insbesondere MDA schliessen ja keine Indivdualitaet aus. MDA ist nicht mit den "one size fits all"-Ansaetzen
von einigen Tools mit Generatoren (die leider oft auch das MDA-Logo tragen) zu verwechseln!
<P>Wichtig ist hier zu erkennen, dass eben individuelle Transformationen (ob generativ oder manuell) hier moeglich
sind bzw. sein muessen. Und demnach kann ich der These, dass MDA nur fuer Prototypen einsetzbar ist, nicht folgen
(und aus meiner mehrjaehrigen praktischen Erfahrung auch nicht bestaetigen). Und eine moegliche Transformation
eines Modellausschnitts mit zwei Klassen und einer Assoziation auf die genannte Plattform, hast du doch selbst
beschrieben... Ob die Entwicklung von Transformationsregeln fuer diesen Fall in einem vernuenftigen Kosten-Nutzen
Verhaeltniss steht, musst du dann entscheiden.

<BR><P>Gruss
<BR>Carsten [email protected]

[Christof Aenderl]

Hallo,
<p>
zunächst wundert es mich auch, dass hier so wenig Beiträge zu finden sind. Besonders nach den guten Artikeln in Ausgabe 9.03 und 10.03 über MDA.</p>
<p>
Ich schreibe zur Zeit meine Bachelor Thesis mit den Schwerpunkten MDA und MVC, d.h. es geht nicht um die Generierung von statischen Komponenten einer Anwendung, wie zum Beispiel Entitäten, sondern vor allem um die Erzeugung von Controllern und die Navigation. In meinem Fall für eine Web Anwendung.</p>
<p>
Meine Erfahrungen, beim Einsatz von MDA sind durchweg positiv. Große Teile meiner Testanwendung werden generiert. Sehr praktisch ist das auch für die Konfigurationsdateien, da diese bei Änderungen im Modell automatisch angepasst werden. Auch wenn diese Anwendung vergleichsweise winzig ist, denke ich wäre das Ergebnis bei einer größeren Anwendung ähnlich. Eine Verfeinerung der Transformationsregeln würde zudem eine Steigerung des generierten Anteils bewirken.</p>
<p>
Das ist auch ein sehr wichtiger Aspekt, wenn es um MDA geht. Das Editieren der Transformationsregeln (meist Generator-Templates) muss möglich sein. Nur so können die gestellten Anforderungen erfüllt werden und theoretisch kann somit ALLES generiert werden. Das Generat ist jedoch immer so gut (oder schlecht) wie seine Vorlage, die Templates. Ob sich der Aufwand lohnt für eine bestimmte Anforderung Transformationsregeln zu entwickeln steht, wie Carsten schreibt im eigenen Ermessen.</p>
<p>
Viele Grüsse<br>
Christo