Model-Driven & Service-Oriented Architectures (MDA + SOA)

Model-Driven & Service-Oriented Architectures (MDA + SOA)

Posts 1-10 of 11
  • Oliver Meimberg
    Oliver Meimberg    Premium Member
    The company name is only visible to registered members.
    andromda im Produktiveinsatz?
    Hallo zusammen!

    Ich arbeite derzeit an einer Publikation zum Thema MDA und beschäftige mich daher im Moment intensiv mit dem MDA-Framework andromda.

    Mich würde interessieren, ob jemand bereits praktische Erfahrungen mit andromda im tatsächlichen Produktiveinsatz, also im Rahmen realer Softwareprojeke, gesammelt hat, bzw. gerade sammelt.

    Einige Stichpunkte:

    - Stärken/Schwächen, K.O.-Kriterien
    - Einarbeitung des Teams
    - Integration in den SE-Prozess und das Konfiguationsmanagement (Versionierung, build, Konsistenzerhaltung der Artefakte)
    - Nutzen von fertigen oder Schreiben von eigenen Cartridges?


    Liebe Grüße aus Berlin,

    Oliver Meimberg
    • 08 Aug 2005, 6:25 pm
  • Alexander Ockl
    Alexander Ockl    Premium Member
    The company name is only visible to registered members.
    Re: andromda im Produktiveinsatz?
    Hallo Herr Meimberg,
    Mich würde interessieren, ob jemand bereits praktische Erfahrungen mit andromda im tatsächlichen Produktiveinsatz, also im Rahmen realer Softwareprojeke, gesammelt hat, bzw. gerade sammelt.
    Hallo Herr Meimberg,

    ich habe AndroMDA sehr erfolgreich bei einem Projekt bei einer deutschen Großbank eingesetzt.
    und zusammen mit JDO (Versant) und EJBs (BEA Weblogic 7 bzw. 8) im Bereich SOA, Datawarehouse
    und Notfallbanking sehr positive Erfahrungen gemacht.

    1. MDA eignet sich insbesondere bei datennaher Entwicklung.
    Hier habe ich eine Generierungsquote von 77% (bezogen auf Klassen)
    und 89% (bezogen auf Lines of Code erreicht).

    2. MDA eignet sich für iterative Entwicklung bei datennaher Entwicklung:
    Ausgehend vom UML Modell hat man eine überschaubare und leicht verständliche
    Diskussionsgrundlage. Man kann einfach "Pfeile" umdrehen und mit minimalem,
    manuellen Aufwand eine neue Version generieren. Zusammen mit JUnit und einem
    Persistenzframework lassen sich dazu Qualität und Datenbankimplementierung
    ebenfalls mit sehr wenig Aufwand realisieren.

    3. Damit kann ich von Anfang an meine Produktivität und Qualität messen und
    positiv, sowie kostentechnisch darstellen.

    4. Es lohnt sich, nicht alles zu generieren.
    Auch hier lauert die alte "Frameworkgefahr". Wird es zu kompliziert bzw. der
    Aufwand zu hoch, ist es besser die "einfache Lösung" auf die herkömmliche Art
    und Weise zu entwickeln.

    5. Kein Reverse Engineering. Hier ist der Architekt gefragt. Durch geschicktes Design,
    Vererbung und Paketierung, kann man Klassen in den "manuellen Code" hinein generieren
    lassen. Es gibt zwar die geschützten Bereiche, doch die umgeht man besser, um nicht die
    Übersicht zu verlieren.

    6. Alles möglichst einfach halten. AndroMDA ist eigentlich nicht schwer zu verwenden. Die
    schlechte Doku macht es einem allerdings sehr schwer, mit diesem Tool umzugehen. Man darf
    nicht vergessen, dass es diese mächtige Software für lau gibt und mit irgendetwas möchte
    Herr Bohlen ja auch sein Geld verdienen ;-)
    Am wichtigsten ist es, die MOF Modelle zu verstehen, die bei den Cardridges liegen, sowie,
    wie man eine eigene Cardridge erstellen und einbinden kann. Die Velocity Templates sind
    sehr einfach verständlich.

    Mir persönlich gefällt AndroMDA sehr gut, da es einfach, effektiv und vor allem mit der
    ANT Einbettung IDE unabhängig ist (das freut die Entwickler). Außerdem kann ich jedes
    UML Tool verwenden, dass XMI 1.4 exportiert.

    Die bereits existierenden Cartridges sehen sehr interessant aus (insbes. die Hibernate
    Cartr.). Ich habe mich allerdings noch nicht mit Ihnen beschäftigen können...

    Ich hoffe, dass hilft Ihnen weiter.

    Herzliche Grüße
    -Alexander Ockl-
    • 08 Aug 2005, 9:13 pm
  • Frank Egger
    Frank Egger    Premium Member
    The company name is only visible to registered members.
    Re: andromda im Produktiveinsatz?
    hallo herr meimberg!

    wir haben andromda in zahlreichen projekten mittlerweile über zwei jahre produktiv im einsatz. derzeit betreue ich eine diplomarbeit, die sich mit dem generator in der webschicht auseinandersetzt.
    wir nutzen dabei die mitgelieferten cartridges von andromda nicht, da wir gänzlich andere anforderungen an unsere architektur haben. ich selbst würde auch empfehlen, die vorhandenen cartridges eher als startpunkt für eine eigene weiterentwicklung und anpassung zu verstehen. aus meiner erfahrung sind sie in großen projekten ohne ergänzungen oder modifikationen schwer verwendbar.

    negativ war lange zeit der etwas größere einarbeitungsaufwand bei der entwicklung eigener cartidges und die etwas dünne dokumentation der version 3.0.
    als eine der großen stärken würde ich die mittlerweile etwas größere community bezeichnen, die sich an den wünschen und vorstellungen der anwender sehr stark und schnell orientiert.
    auch die angestrebte abstraktion auf die version des uml-metamodells und damit der xmi-version oder der eingesetzten template-sprache machen den generator zukünftig bestimmt sehr interessant.

    unser team hat sich schnell in den für einen mdsd-prozess üblichen rollen wiedergefunden und eingelebt. architekten und entwickler arbeiten eng zusammen, eine klare trennung zwischen fachlogik-implementiereren und fachdesignern existiert bei uns derzeit nicht. das feedback der entwickler führt dabei permanent in dem architektur-entwicklerstrang zu ergänzungen und optimierungen. die eigenentwickelten cartridges zielen stark auf die einzelnen schichten der architektur (web, business, persistence) ab und besitzen erweiterungen für z.b. webservices, mbeans-konfiguration, etc.. dadruch wird die bildung von anwendungsfamilien oder einzelnen produktlinien unterstützt.
    der bei uns vorhandene iterativ-inkrementelle und architekturzentrierte se-prozess wird durch den einsatz des generators optimal verstärkt. modell-partitionierung wird vom generator in der version 3.0 unterstützt und erlaubt so auch in großen teams ein relativ paralleles arbeiten an fachmodellen.

    alles in allem hat uns der generator noch nicht enttäuscht und uns sehr in unseren projekten unterstützt.

    ich hoffe, dass ich ihnen ein paar nützliche infos bieten konnte.

    viele grüße,
    frank egger
    • 11 Aug 2005, 3:23 pm
  • Wolfgang Neuhaus
    Wolfgang Neuhaus    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: andromda im Produktiveinsatz?
    Hallo Frank!

    Ich denke, die letzte Aussage ist entscheidend: der generator hat uns noch nicht enttäuscht. Denn im Vordergrund steht meiner Ansicht nach die Methodik und nicht die konkrete Generator-Technik. Und da sehe ich es als wichtigste Eigenschaft an, dass die eingesetzte Technik die Methodik nicht behindert.

    Aus unserer Erfahrung - die in den meisten Projekten mit dem Generator openArchitectureWare beruht - ist die Stärke der flexiblen Anpassung eines Generators an die eigene Architektur deutlich höher zu bewerten, als fertige Cartridges. Denn hier haben wir bisher in ausnahmslos jedem Projekt die Erfahrung gemacht, dass die Cartridges nicht 1:1 eingesetzt werden. Damit sind sie zwar als Einstiegshilfe und Blaupause hilfreich, dienen aber in der Regel nicht dauerhaft als Grundlage für die eigene Entwicklung. Hier laufen die Entwicklungen zwischen Open Source Cartridges und eigenen, angepassten Cartridges zu schnell auseinander.

    Aussichtsreicher wird das ganze meiner Ansicht nach bei Verwendung von "Metaframeworks" wie Spring, da ich dann gegen eine relativ stabile Plattform generieren und in einzelnen Architekturaspekten unterschiedliche Realisierungskomponenten einsetzen kann.

    Hier ist für den Bereich WebControls das Spring WebFlow Projekt (
    http://www.theserverside.com/articles/article.tss?l=SpringWe... ) recht spannend.

    Bis dann,

    Wolfgang



    Frank Egger schrieb:
    hallo herr meimberg!
     
    wir haben andromda in zahlreichen projekten mittlerweile über zwei jahre produktiv im einsatz. derzeit betreue ich eine diplomarbeit, die sich mit dem generator in der webschicht auseinandersetzt. wir nutzen dabei die mitgelieferten cartridges von andromda nicht, da wir gänzlich andere anforderungen an unsere architektur haben. ich selbst würde auch empfehlen, die vorhandenen cartridges eher als startpunkt für eine eigene weiterentwicklung und anpassung zu verstehen. aus meiner erfahrung sind sie in großen projekten ohne ergänzungen oder modifikationen schwer verwendbar.
     
    negativ war lange zeit der etwas größere einarbeitungsaufwand bei der entwicklung eigener cartidges und die etwas dünne dokumentation der version 3.0.
    als eine der großen stärken würde ich die mittlerweile etwas größere community bezeichnen, die sich an den wünschen und vorstellungen der anwender sehr stark und schnell orientiert. auch die angestrebte abstraktion auf die version des uml-metamodells und damit der xmi-version oder der eingesetzten template-sprache machen den generator zukünftig bestimmt sehr interessant.
     
    unser team hat sich schnell in den für einen mdsd-prozess üblichen rollen wiedergefunden und eingelebt. architekten und entwickler arbeiten eng zusammen, eine klare trennung zwischen fachlogik-implementiereren und fachdesignern existiert bei uns derzeit nicht. das feedback der entwickler führt dabei permanent in dem architektur-entwicklerstrang zu ergänzungen und optimierungen. die eigenentwickelten cartridges zielen stark auf die einzelnen schichten der architektur (web, business, persistence) ab und besitzen erweiterungen für z.b. webservices, mbeans-konfiguration, etc.. dadruch wird die bildung von anwendungsfamilien oder einzelnen produktlinien unterstützt. der bei uns vorhandene iterativ-inkrementelle und architekturzentrierte se-prozess wird durch den einsatz des generators optimal verstärkt. modell-partitionierung wird vom generator in der version 3.0 unterstützt und erlaubt so auch in großen teams ein relativ paralleles arbeiten an fachmodellen.
    alles in allem hat uns der generator noch nicht enttäuscht und uns sehr in unseren projekten unterstützt.
     
    ich hoffe, dass ich ihnen ein paar nützliche infos bieten konnte.
     
    viele grüße,
    frank egger
    • 18 Aug 2005, 10:30 am
  • Oliver Meimberg
    Oliver Meimberg    Premium Member
    The company name is only visible to registered members.
    Re^2: andromda im Produktiveinsatz?
    Hallo Herr Egger,

    vielen Dank für die Antwort.

    wir nutzen dabei die mitgelieferten cartridges von andromda nicht, da wir gänzlich andere anforderungen an unsere architektur haben. ich selbst würde auch empfehlen, die vorhandenen cartridges eher als startpunkt für eine eigene weiterentwicklung und anpassung zu verstehen. aus meiner erfahrung sind sie in großen projekten ohne ergänzungen oder modifikationen schwer verwendbar.
    Ich habe mich in der letzten Zeit recht eingehend mit der bpm4struts Cartridge befasst und musste ähnliches feststellen: Die Cartridge ist recht beeindruckend und zeigt gut, was alles möglich ist, trägt aber für die Praxis in den meisten Fällen wahrscheinlich nicht.

    Aber ein MDSD bzw MDA/D Prozess bedeutet ja auch nicht, fertige Applikationsgeneratoren zu bedienen, sondern die parallele und modellgetriebene weiterentwicklung von Architektur/Generator und Applikation.

    negativ war lange zeit der etwas größere einarbeitungsaufwand bei der entwicklung eigener cartidges und die etwas dünne dokumentation der version 3.0.
    Da wühle ich mich gerade durch ;)

    derzeit nicht. das feedback der entwickler führt dabei permanent in dem architektur-entwicklerstrang zu ergänzungen und optimierungen.
    Das erfordert natürlich einen entsprechenden Softwareentwicklungsprozes, genau wie bei der Frameworkentwicklung: Parallele Entwicklung von Framework/Generatror und n darauf aufbauenden Projekten.

    Das kann aus meiner Sicht jedoch erst dann tatsächlich funktionieren, wenn die Archiktektur weitestgehend stabil ist und sich keine grundsätzlichen änderungen mehr ergeben. Denn das übliche Problem bei der Entwicklung von 1 Framework + n Projekte ist ja immer die Abwärtskombatibilität, möchte man die Applikationsentwicker (hier wären es genaugenommen die "PIM-Markierer" und Implementierer) nicht ständig mit rückwirkenden Änderungen stressen.

    alles in allem hat uns der generator noch nicht enttäuscht und uns sehr in unseren projekten unterstützt.
     
    ich hoffe, dass ich ihnen ein paar nützliche infos bieten konnte.
    Ja, vielen Dank!

    viele grüße,
    frank egger
    Gruß,

    Oliver Meimberg
    • 24 Aug 2005, 08:57 am
  • Sven Efftinge
    Sven Efftinge    Premium Member
    The company name is only visible to registered members.
    Re^3: andromda im Produktiveinsatz?
    Hi Wolfgang,

    Wolfgang Neuhaus schrieb:
    Aus unserer Erfahrung - die in den meisten Projekten mit dem Generator openArchitectureWare beruht - ist die Stärke der flexiblen Anpassung eines Generators an die eigene Architektur deutlich höher zu bewerten, als fertige Cartridges. Denn hier haben wir bisher in ausnahmslos jedem Projekt die Erfahrung gemacht, dass die Cartridges nicht 1:1 eingesetzt werden. Damit sind sie zwar als Einstiegshilfe und Blaupause hilfreich, dienen aber in der Regel nicht dauerhaft als Grundlage für die eigene Entwicklung. Hier laufen die Entwicklungen zwischen Open Source Cartridges und eigenen, angepassten Cartridges zu schnell auseinander.
    Was einerseits natürlich an den unterschiedlichen Anforderungen liegt, andererseits aber auch an zwei weiteren
    Punkten:

    1) Metamodelle bzw. DSLs für techn. Architekturen sind leider meistens nicht besonders ausgereift. Das Problem wird die Zeit lösen, hier sind standardisierte Cartrdiges durchaus sinnvoll, weil best practices bekannt sind. Beispiel: Domänenmodell

    2) Das Hauptproblem ist die schlechte Erweiterbarkeit von sog. Cartridges. Gute Cartrdiges sollten ausreichend Extension-Points anbieten, damit der Benutzer Dinge verändern, wegnehmen, hinzufügen kann, ohne das Cartridge zu ändern. Dafür sollte es Sprachkonstrukte geben, die es erlauben eben solche extension-points zu deklarieren.

    openArchitectureWare wird dieses Problem in der Version 4 folgendermassen angehen:

    1) Es wird eine einfache Transformationsprache geben, über die man dann Modelle eines beliebigen Metamodells in Modelle eines spezifischen Cartridge-Metamodells transformieren kann. (Hier also nicht auf die Cartridge spezifischen Abstraktion auf Modellebene angeweisen ist)

    2) Die Templatesprache Xpand wird einen Aspektmechanismus erhalten, mit dem es dann möglich ist bestimmte Templates aus einer Cartridge über Konfiguration durch eigene Templates auszutauschen.

    3) Cartridges können nicht nur ein Satz von Templates, die sich auf ein bestimmtes Metamodell beziehen, sein , sondern auch ein mehrstufiger Generator-Abschnitt, also z.B. validierung - transformation - generierung. Solche Cartrdiges werden in einer konfigurationsdatei zusammengeschnürt und können dann als Blackbox konfiguriert und genutzt werden.

    Gruß aus Flensburg,
    Sven
    • 02 Sep 2005, 1:23 pm
  • Matthias Bohlen
    Matthias Bohlen    Premium Member
    The company name is only visible to registered members.
    Re^2: andromda im Produktiveinsatz?
    Alexander Ockl schrieb:

    ich habe AndroMDA sehr erfolgreich bei einem Projekt bei einer
    deutschen Großbank eingesetzt.
    und zusammen mit JDO (Versant) und EJBs (BEA Weblogic 7 bzw. 8) im
    Bereich SOA, Datawarehouse
    und Notfallbanking sehr positive Erfahrungen gemacht.
    Hallo Herr Ockl,

    das klingt ja sehr interessant! Ich würde bei Gelegenheit gern mehr über das Projekt erfahren!

    5. Kein Reverse Engineering. Hier ist der Architekt gefragt. Durch
    geschicktes Design,
    Vererbung und Paketierung, kann man Klassen in den "manuellen
    Code" hinein generieren
    lassen. Es gibt zwar die geschützten Bereiche, doch die umgeht man
    besser, um nicht die
    Übersicht zu verlieren.
    Reverse Engineering ist ein beliebtes und häufig nachgefragtes Thema. Es stellt sich jedoch in der Praxis heraus, dass man Reverse Engineering letztendlich nicht benötigt. Der reine Forward Generation Ansatz von einem Modell mit hohem Abstraktionsniveau über Zwischenmodelle mit mittlerer Abstraktion bis hin zum Code mit sehr niedriger Abstraktion funktioniert in der Praxis sehr schön. Der umgekehrte Weg würde sich schwierig gestalten: Es ist nicht Aufgabe eines Codegenerators, sich Gedanken zu machen, was denn auf der Ebene des High-Level-Businessmodells wohl gemeint gewesen sein könnte, wenn der User im generierten Code z.B. eine Namensänderung gemacht hat.


    6. Alles möglichst einfach halten. AndroMDA ist eigentlich nicht
    schwer zu verwenden. Die
    schlechte Doku macht es einem allerdings sehr schwer, mit diesem
    Tool umzugehen.
    Hmmm... schlechte Dokumentation? Bis etwa Ende 2004 wurde uns das nachgesagt. In den letzten Monaten haben wir deshalb hohen Aufwand in gute Dokumentation investiert. Speziell unser Committer Wouter Zoons hat sich da hervorgetan und sehr ausführliche How-To's mit Schritt-für-Schritt-Vorgehen geschrieben. Sie finden die aktuelle Dokumentation unter http://docs.andromda.org/ - schauen Sie noch einmal rein, es lohnt sich!

    Man darf
    nicht vergessen, dass es diese mächtige Software für lau gibt und
    mit irgendetwas möchte
    Herr Bohlen ja auch sein Geld verdienen ;-)
    Natürlich verdiene ich gern Geld, das ist klar, zum Beispiel mit dem "AndroMDA Boot Camp Training, von Null bis zur eigenen Cartridge in vier Tagen", mehr Info unter http://www.andromda.com . Doch ist es keinesfalls so, dass wir bei AndroMDA.org deshalb extra wenig Doku schreiben würden, ganz im Gegenteil! :-) Doku und Training ergänzen sich gegenseitig. In der Doku steht wie es "der reinen Lehre nach" funktioniert; im Training hingegen gehe ich mit den Teilnehmern auch die ganzen Kleinigkeiten und Stolperfallen durch, die in der Praxis auftreten. Wir üben auch das Arbeiten mit AndroMDA im Team, gestützt auf ein Maven-Repository und einen CVS-Server für Modell und Code. Denn: Entscheidend für den Erfolg von MDA ist die Einbettung in einen leicht handhabbaren Entwicklungsprozess!

    Am wichtigsten ist es, die MOF Modelle zu verstehen, die bei den
    Cardridges liegen,
    Das sind keine MOF-Modelle, sondern UML-Modelle für Metafassaden. Metafassaden sind Klassen, welche die "rein datenhaltigen" Metaklassen des drunterliegenden Metamodells (z.B. UML) verpacken und mit codegenerierendem Verhalten anreichern. Dadurch vereinfachen sich die Templates sehr stark. Metafassaden werden von AndroMDA zur Codegenerierungszeit automatisch instanziiert, wenn die passende Metaklasse des drunterliegenden Metamodells erkannt wird bzw. wenn weitere Bedingungen (z.B. gesetzte Stereotypen) erfüllt sind. Cartridge-Autoren können sich einfach eigene Metafassaden modellieren, generieren und dann mit selbstgeschriebenem Codegenerierungsverhalten füllen.

    Freundliche Grüße,
    M. Bohlen
    Gründer von AndroMDA.org und AndroMDA.com
    This post was modified on 12 Sep 2005 at 01:14 pm.
    • 12 Sep 2005, 1:09 pm
  • Matthias Bohlen
    Matthias Bohlen    Premium Member
    The company name is only visible to registered members.
    Re^3: andromda im Produktiveinsatz?
    Hallo Wolfgang!


    Wolfgang Neuhaus schrieb:

    Ich denke, die letzte Aussage ist entscheidend: der generator hat uns noch nicht enttäuscht. Denn im Vordergrund steht meiner Ansicht nach die Methodik und nicht die konkrete Generator-Technik. Und da sehe ich es als wichtigste Eigenschaft an, dass die eingesetzte Technik die Methodik nicht behindert.
    Ganz richtig! Die eingesetzte Tool-Chain muss einen iterativ-inkrementellen Entwicklungsprozess sauber unterstützen. Das fängt schon beim Modellierunstool an. In der Praxis hat sich gezeigt, dass es einseits wichtig ist, dass auf dem Entwicklerplatz alles richtig und schnell funktioniert, dass aber zusätzlich derselbe Prozess auch "im Batch" funktionieren muss, z.B. wenn Tools wie CruiseControl die Projekte automatisch bauen. Hier wirken manche ältere Tools (konkrete Namen nenne ich gern mal im persönlichen Gespräch!) etwas hinderlich, die im Batch nur mit Kunstgriffen dazu überredet werden können, ihr Modell im XMI-Format preiszugeben.

    Aus unserer Erfahrung - die in den meisten Projekten mit dem Generator openArchitectureWare beruht - ist die Stärke der flexiblen Anpassung eines Generators an die eigene Architektur deutlich höher zu bewerten, als fertige Cartridges. Denn hier haben wir bisher in ausnahmslos jedem Projekt die Erfahrung gemacht, dass die Cartridges nicht 1:1 eingesetzt werden. Damit sind sie zwar als Einstiegshilfe und Blaupause hilfreich, dienen aber in der Regel nicht dauerhaft als Grundlage für die eigene Entwicklung. Hier laufen die Entwicklungen zwischen Open Source Cartridges und eigenen, angepassten Cartridges zu schnell auseinander.
    Das kommt ganz auf das Projekt an. Die meisten Projekte machen es wie Herr Egger: sie passen die Cartridges optimal an die eigene Zielarchitektur an, das ist sicherlich der typische Anwendungsfall für AndroMDA. Dabei lassen sich die fertigen Cartridges gut als Blaupause benutzen, weil sie sehr schön zeigen, "was alles geht".

    Ich habe jedoch auch schon Projekte gesehen, die die fertigen Cartridges (z.B. die Spring-Cartridge) einfach nehmen und im Projekt zunächst unverändert einsetzen. Dabei dient die kondensierte Erfahrung, die in der fertigen Cartridge steckt, als Treibstoff für einen Jump Start. Nach ein bis drei Monaten im Projekt, als sich die Architekten entsprechend sicher fühlten, fingen sie natürlich an, die Cartridge zu erweitern. Ein Glücksfall für AndroMDA: einer der besten Architekten wurde zum Committer und fügte seine Praxiserfahrung mit der Spring-Cartridge gleich zum Code hinzu. Dadurch ist bei uns die Spring-Cartridge eine der stärksten und solidesten geworden.

    Insofern: Fertige Cartridges zeigen wie es geht und ermöglichen einen schnellen Start. Später löst man sich von der Vorgabe und schreibt sich Cartridges, die optimal zur eigenen Zielarchitektur passen. Als Zwischenschritt bietet sich das Erweitern existierender Cartridges an. Über Extension Points in AndroMDA-Cartridges schreibe ich weiter unten noch etwas.

    Freundliche Grüße,
    M. Bohlen
    • 12 Sep 2005, 1:33 pm
  • Matthias Bohlen
    Matthias Bohlen    Premium Member
    The company name is only visible to registered members.
    Re^4: andromda im Produktiveinsatz?
    Hallo Sven,
    (ich hoffe, ich darf unter Kollegen das "Open Source-Du" verwenden?)

    Sven Efftinge schrieb:

    2) Das Hauptproblem ist die schlechte Erweiterbarkeit von sog. Cartridges. Gute Cartrdiges sollten ausreichend Extension-Points anbieten, damit der Benutzer Dinge verändern, wegnehmen, hinzufügen kann, ohne das Cartridge zu ändern. Dafür sollte es Sprachkonstrukte geben, die es erlauben eben solche extension-points zu deklarieren.
    Genau. In AndroMDA gibt es zwei Möglichkeiten dafür:
    * einzelne Cartridge-Bestandteile komplett überschreiben
    * neue Bestandteile von außen hinzukonfigurieren
    * einzelne Cartridge-Bestandteile an vordeklarierten "Merge Points" erweitern

    Alle diese Konzepte gibt es in AndroMDA schon seit der Version 3.0. Dokumentiert ist das auf der Seite http://team.andromda.org/docs/andromda-cartridges/ in den Abschnitten "Overriding cartridge resources" und "Merging cartridge resources". Auf diese Art und Weise können Sie z.B. eigene Templates oder Mapping-Regeln hinzufügen, ohne gleich die ganze Cartridge ändern zu müssen.

    openArchitectureWare wird dieses Problem in der Version 4 folgendermassen angehen:
     
    1) Es wird eine einfache Transformationsprache geben, über die man dann Modelle eines beliebigen Metamodells in Modelle eines spezifischen Cartridge-Metamodells transformieren kann. (Hier also nicht auf die Cartridge spezifischen Abstraktion auf Modellebene angeweisen ist)
    2) Die Templatesprache Xpand wird einen Aspektmechanismus erhalten, mit dem es dann möglich ist bestimmte Templates aus einer Cartridge über Konfiguration durch eigene Templates auszutauschen.
     
    3) Cartridges können nicht nur ein Satz von Templates, die sich auf ein bestimmtes Metamodell beziehen, sein , sondern auch ein mehrstufiger Generator-Abschnitt, also z.B. validierung - transformation - generierung. Solche Cartrdiges werden in einer konfigurationsdatei zusammengeschnürt und können dann als Blackbox konfiguriert und genutzt werden.
    Schön wenn Ihr das jetzt in V4 auch so macht! So wachsen die Konzepte unserer beiden Generatoren immer weiter zusammen. Bei AndroMDA sind in den Metafassaden, die in einer Cartridge gebündelt sind, bereits OCL-Statements mit hineinmodelliert und -generiert, so dass Modellvalidierung direkt auf Metamodellebene durchgeführt wird. Die Methoden in den Metafassaden sorgen in Version 3 noch für die Transformation, bevor die Templates greifen und das spezifische Cartridge-Metamodell in Text transformieren. Für AndroMDA Version 4 werden wir eine Open Source Modelltransformations-Engine einbinden (eng an den QVT-Standard der OMG angelehnt), so dass die Metafassaden keinen echten Transformationscode mehr enthalten und sich in ihrer Bedeutung mehr vom Quellmodell weg- und zum cartridge-spezifischen Metamodell hin-entwickeln werden.

    Ich finde es schön, dass AndroMDA und openArchitectureware unabhängig voneinander zu denselben Ergebnissen kommen. Jetzt müsste die OMG nur noch standardisieren, wie typische Generatorbestandteile (Metamodelle, Validierungsregeln, Transformationen, Templates) auszusehen haben, dann könnten wir diese bereits zwischen den Generatoren austauschen und so tatsächlich in einem neuen Sinne "portabel" werden.

    Zum Austausch von Metamodellen ist ja mit MOF/XMI bereits ein Standard vorhanden (Problem ist in der Praxis nur, dass nicht alle sich daran halten und z.B. die "Eclipser" mit EMF meinen, ihr eigenes inkompatibles Süppchen kochen zu müssen und dadurch gute Ansätze wie Omondo vom Pfad der Tugend abbringen).

    Constraints zur Modellvalidierung kann man mit OCL sehr schön darstellen, was ja auch gut standardisiert ist. Auch für Transformationen sieht es ja mit QVT nicht schlecht aus.

    Also könnten wir in Kürze bereits Metamodelle, Constraints und Transformationen austauschen. Für Templatesprachen gibt es ja noch keinen richtigen Standard, auch da sollte sich die OMG einmal "outen".

    Ich finde die Entwicklung von MDA sehr spannend. Sehen wir einmal, wie alles weitergeht.

    Gruß aus Flensburg,
    Sven
    Grüße aus Meckenheim bei Bonn, und frohe "Coopetition" ... :-)
    Matthias
    • 12 Sep 2005, 1:57 pm
  • Alexander Ockl
    Alexander Ockl    Premium Member
    The company name is only visible to registered members.
    Re^3: andromda im Produktiveinsatz?
    Hallo, Herr Bohlen,

    vielen Dank für Ihre ausführliche Antwort.

    das klingt ja sehr interessant! Ich würde bei Gelegenheit gern mehr über das Projekt erfahren! Sehr gerne. Vielleicht können wir uns ja mal kurzschließen. Würde gern
    mehr erfahren, wie sie zu AndroMDA gekommen sind.

     
    5. Kein Reverse Engineering. Hier ist der Architekt gefragt. Durch geschicktes Design,
    Vererbung und Paketierung, kann man Klassen in den "manuellen Code" hinein generieren
    lassen. Es gibt zwar die geschützten Bereiche, doch die umgeht man
    besser, um nicht die
    Übersicht zu verlieren.
     
    Reverse Engineering ist ein beliebtes und häufig nachgefragtes Thema. Es stellt sich jedoch in der Praxis heraus, dass man Reverse Engineering letztendlich nicht benötigt. Der reine Forward Generation Ansatz von einem Modell mit hohem Abstraktionsniveau über Zwischenmodelle mit mittlerer Abstraktion bis hin zum Code mit sehr niedriger Abstraktion funktioniert in der Praxis sehr schön. Der umgekehrte Weg würde sich schwierig gestalten: Es ist nicht Aufgabe eines Codegenerators, sich Gedanken zu machen, was denn auf der Ebene des High-Level-Businessmodells wohl gemeint gewesen sein könnte, wenn der User im generierten Code z.B. eine Namensänderung gemacht hat.
     
     
    6. Alles möglichst einfach halten. AndroMDA ist eigentlich nicht schwer zu verwenden. Die schlechte Doku macht es einem allerdings sehr schwer, mit diesem Tool umzugehen.
     
    Hmmm... schlechte Dokumentation? Bis etwa Ende 2004 wurde uns das nachgesagt. In den letzten Monaten haben wir deshalb hohen Aufwand in gute Dokumentation investiert. Speziell unser Committer Wouter Zoons hat sich da hervorgetan und sehr ausführliche How-To's mit Schritt-für-Schritt-Vorgehen geschrieben. Sie finden die aktuelle Dokumentation unter http://docs.andromda.org/ - schauen Sie noch einmal rein, es lohnt sich!     Ich habe mal einen Blick riskiert. Sieht ja aus, als ob AndroMDA hier zugelegt hat.
    Im Februar war die Doku leider noch sehr spärlich oder gut versteckt. Da hatte ich
    als "Newbie" schon mächtig zu kämpfen...

     
    Man darf
    nicht vergessen, dass es diese mächtige Software für lau gibt und mit irgendetwas möchte
    Herr Bohlen ja auch sein Geld verdienen ;-)
     
    Natürlich verdiene ich gern Geld, das ist klar, zum Beispiel mit dem "AndroMDA Boot Camp Training, von Null bis zur eigenen Cartridge in vier Tagen", mehr Info unter http://www.andromda.com . Doch ist es keinesfalls so, dass wir bei AndroMDA.org deshalb extra wenig Doku schreiben würden, ganz im Gegenteil! :-) Doku und Training ergänzen sich gegenseitig. In der Doku steht wie es "der reinen Lehre nach" funktioniert; im Training hingegen gehe ich mit den Teilnehmern auch die ganzen Kleinigkeiten und Stolperfallen durch, die in der Praxis auftreten. Wir üben auch das Arbeiten mit AndroMDA im Team, gestützt auf ein Maven-Repository und einen CVS-Server für Modell und Code. Denn: Entscheidend für den Erfolg von MDA ist die Einbettung in einen leicht handhabbaren Entwicklungsprozess!     Da stimme ich Ihnen besonders hinsichtlich des letzten Punktes zu. Nach
    meiner Erfahrung aus dem Projekt ist es insbesondere wichtig, auch agil
    entwickeln zu können. Die Aussage: mit MDA kann man nur schwerfällig
    und langfristig Software zu erstellen, hat sich bei mir zumindest als Vorurteil
    herausgestellt. Aus Management Sicht gefällt mir besonders, dass man
    die Aufwände und Ersparnisse ganz gut darstellen kann. Meiner Meinung
    nach hängt die Effektivität der MDA aber auch stark von der Aufgabenstellung,
    also von der Komplexität ab, inwieweit man Patterns extrahieren bzw. ableiten
    kann.

    Das sind keine MOF-Modelle, sondern UML-Modelle für Metafassaden. Metafassaden sind Klassen, welche die "rein datenhaltigen" Metaklassen des drunterliegenden Metamodells (z.B. UML) verpacken und mit codegenerierendem Verhalten anreichern. Dadurch vereinfachen sich die Templates sehr stark. Metafassaden werden von AndroMDA zur Codegenerierungszeit automatisch instanziiert, wenn die passende Metaklasse des drunterliegenden Metamodells erkannt wird bzw. wenn weitere Bedingungen (z.B. gesetzte Stereotypen) erfüllt sind. Cartridge-Autoren können sich einfach eigene Metafassaden modellieren, generieren und dann mit selbstgeschriebenem Codegenerierungsverhalten füllen. Ich muß zugeben, dass ich mich als Pragmatiker etwas schwer mit der
    Nomenklatur tue. Zur Erstellung einer eigenen Metafacade bin ich leider
    nicht gekommen. Bei der Erstellung meiner Cartridge hätte ich mir allerdings
    manchmal gewünscht, wenn die Templatesprache (Velocity) etwas mehr
    Funktionalität zu Verfügung gestellt hätte. Hier allerdings auf ein anderes
    Produkt zu setzten ist mit den wenigen Ressourcen allerdings schon sehr
    sinnvoll...

    Viele Grüße nach Meckenheim
    -Alexander Ockl-
    • 13 Sep 2005, 02:30 am