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

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

Posts 11-11 of 11
  • Sven Efftinge
    Sven Efftinge    Premium Member
    The company name is only visible to registered members.
    Re^5: andromda im Produktiveinsatz?
    Hallo Matthias,

    Matthias Bohlen schrieb:
    (ich hoffe, ich darf unter Kollegen das "Open Source-Du" verwenden?)
    Na klar!

    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
    Schön, das wusste ich nicht. Im JM hat der Peter Friese Cartridges ja eher als anzupassende Blaupause zum Starten neuer Projekte beschrieben, was aus meiner Sicht auch nicht ganz schlecht ist, aber es eben leider nicht ermöglicht neu hinzugekommene Features und Erweiterungen zu nutzen.
    Ich hab gerade gesehen, dass Ihr FreeMarker als generator anbinden wollt (bzw. angebunden habt)
    Ist das wirklich ein Mehrwert gegenüber Velocity? Das sind ja im PRinzip genau die gleichen Konzepte, oder?
    Hast Du Dir schonmal Xpand oder auch Mofscript (http://www.modelbased.net/mofscript/) angeschaut? Die passen wesentlich besser zu CodeGenerierung. Z.B. brauchst du da nicht ausserhalb der templates definieren, in welcher datei das generat gespeichert werden soll.

     
    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".
    Ist ne gute doku, nur leider schwer zu finden :-)

     
    Schön wenn Ihr das jetzt in V4 auch so macht! So wachsen die Konzepte unserer beiden Generatoren immer weiter zusammen.
    Das finde ich auch sinnvoll. Genauso machen wir das aber nicht.
    Die Templateaspekte sind ein Sprachkonstrukt. keine Konfiguration von aussen und die Transformationsprache eben eine neue, auf modeltransf. spezialisierte Sprache.

    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.
    In der Praxis habe ich auf einem Metamodell mehrere verschieden Validierungen
    z.B. brauchen Entities zur Modellierungszeit keine PKs, aber nach der Transformation schon.
    Da kann ich die Semantik nicht direkt, am Metamodell halten.
    Ansonsten macht das aber sicherlich sinn, wobei ich
    1) textuelle information, lieber nicht in UML-tools schreibe und
    2) die meisten UML-tools mich auch nicht besonders gut dabei unterstützen

    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.
    Interessant. Welche engine wollt ihr da benutzen?

     
    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.
    Ja, oder wir warten nicht auf praxisferne Standards, die dann doch keiner benutzt, sondern einigen uns auf pragmatische quasistandards. Das ist ja ein natürlicher Prozess, wo man glücklicher Weise gar nicht viel lenken muss :-)
    Wenn standards gut sind, bin ich natürlich immer Freund!

     
    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).
    Was XMI angeht, müsstest du eigentlich wissen (habt ihr da keinen Ärger, mit demParsen von toolspezifischem XMI?), dass der standard sehr lose ist, was dazu führt, dass du auch zwischen "Standardkonformen"-UML-Tools nicht austauschen kannst.

    EMF baut darüber hinaus nicht auf das etwas veraltete MOF 1.x, sondern auf EMOF (subset von MOF 2.0). Ausserdem gibt es dafür noch keine standardisierte Abbildung auf Java (also JMI).
    IBM steht da aber mit der OMG in Kontakt.

     
    Constraints zur Modellvalidierung kann man mit OCL sehr schön darstellen, was ja auch gut standardisiert ist.
    OCL hat ein paar nette shortcuts, zur Navigierung über objekt graphen. Leider gibt es keine ordentliche Toolunterstützung, oder?
    Ausserdem ist die konkrete Syntax ein wenig ungewöhnlich, wie ich finde.
    Ansonsten ist OCL, speziell der Expression part, recht gut. Und die idee das in anderen (Tranfo- und Generierungs-)Sprachen wieder zu verwenden wirklich sinnvoll.

    Auch für Transformationen sieht es ja mit QVT nicht schlecht aus.
    Gibt's da schon konrete Ergebnisse?
    So viel ich weiss, ist das bisher ein RFP, auf den es zugegebenermassen einige interessante Antworten gibt.

     
    Also könnten wir in Kürze bereits Metamodelle, Constraints und Transformationen austauschen.
    Können wir auch jetzt schon. Mit der workflow engine von oAW 4, kannst du auch androMDA cartridges in deinen generator reinhängen.

    Für Templatesprachen gibt es ja noch keinen richtigen Standard, auch da sollte sich die OMG einmal "outen".
    Da gibt es auch einen RFP (http://www.omg.org/cgi-bin/doc?ad/04-04-07)

     
    Ich finde die Entwicklung von MDA sehr spannend. Sehen wir einmal, wie alles weitergeht.
    Ich auch, wobei ich auch "nicht MDA-standard" Entwicklungen und Konzepte, wie MS software factories oder EMF, spannend finde.

    Grüße aus Meckenheim bei Bonn, und frohe "Coopetition" ... :-)
    Matthias
    Gruss (heute aus Bonn),
    Sven
    • 15 Sep 2005, 1:01 pm