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

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

Posts 1-10 of 15
  • Boris Holzer
    Boris Holzer    Premium Member
    The company name is only visible to registered members.
    "Sanfte" Einführung von MDSD
    "Wir wollen mit MDA/MDSD unsere Effizienz steigern - aber wie ?"
    - "Wie hoch ist der hierfür nötige Invest ?"
    - "Gefährden wir unseren gut funktionierenden Softwareentwicklungsprozess ?"
    - "Wie wird die Akzeptanz im Team sein ?"

    Diese Fragen hat man sich zu Beginn meines letzen Kundenprojektes gestellt.
    Weil es ein recht kritisches Projekt war, hatte man sich aus Gründen der Risikominimierung eigentlich gegen eine Prozessinovation in diesem Projekt entschlossen.
    Das fand ich recht schade :-(.
    Andererseits war ich motiviert, den Prozess vielleicht doch etwas upzugraden.
    Zum Glück konnte ich mir zu einer recht frühen Projektphase etwas Freiraum schaffen :-)
    Diesen hab ich dann genutzt, einen MDSD - Generator für den Entity-Layer zu bauen.
    Zugegem - ich hatte hinsichtlich der Voraussetzung etwas Glück:
    Es war ein klares Programmiermodell für das Persistenzframework vergegeben;
    man könnte im Nachhein das etablierte Vorgehen auch schon als MDSD - Ansatz bezeichnen - allerdings mit einem menschlichen und recht gelangweiltem Generator.
    Mit dem maschinellen Generator wurde die entsprechenden Artefakte schließlich deutlich schneller erstellt, als ursprünglich im Projektplan vorgesehen.
    Der MDSD-Ansatz hat beim Kunden zwar immer noch prototypischen Charakter, aber die Saat keimt.

    Vor diesem Hintergrund sind meine Lessons Learned hinsichtlich eines sanften Einführung von MDSD:

    Gib ein klares Programmiermodell vor !
    Sollte diese nicht vorhanden sein, reicht die Definition eines solchen als erste Innovation (wie oben: MDSD mit menschlichem Generator).

    Verwende eine einfache Design-Sprache
    - Der Standardentwickler sollte das formale Modell lesen und verstehen können.
    - Alle modellierten Artefakte sollen visualisierbar sein (und zwar nicht erst im dritten Untermenü, sondern im Diagramm)

    Vermeide die Einarbeitung in den Generator !
    Da gibt's 3 Möglichkeiten:
    - Nutz den Mensch als Generator - das geht aber nur temporär, denn das ist ineffizient und langweilig (s.o)
    - Bau einen Internen auf
    - Frage einen Externen mit Ahnung

    Mach Dich nicht toolabhängig !
    - Der generierte Code muss klar und verständlich sein. Man sollte den Generator jederzeit abschalten können.
    - Man sollte die generierten Artefakte jederzeit auf Korrektheit prüfen können.

    Fazit: Eine sanfte Einführung erfordert kleine schnelle Schritte !
    - "KLEIN": Nicht zu viel Innovation auf einmal. Designsprache & Generat müssen nachvollziehbar sein. Man muss auch keinen Komplette Applikationsrahmen generieren - konzentriere Dich lieber auf einen einzelnen Layer.
    - "SCHNELL": Achte darauf, dass innerhalb eines Projektes ein messbarer ROI erzeugt wird. Das Argument zieht immer.
    • 17 Nov 2005, 7:19 pm
  • Karsten Thoms
    Karsten Thoms
    The company name is only visible to registered members.
    Re: "Sanfte" Einführung von MDSD
    Hi Boris!

    Ich habe ähnliche Erfahrung mit meinem aktuellen Projekt. Auch hier konnten wir in einer "Vorlaufphase" einen Generator für ein paar Standardprobleme aufbauen. Für stark repetitive Aufgaben (=Infrastrukturcode) hat man das auch eingesehen. Das zugrunde liegende Programmiermodell hat sich über eine etwas längere Zeit im vorhergehenden Projekt aufgebaut. Es ist zwar teilweise nicht gut, aber weitgehend von allen Entwicklern verstanden. Für die Modellierung unserer "statischen" Elemente haben wir ein Verfahrensdokument aufgesetzt, anhand dessen in enger Zusammenarbeit exemplarisch ein neues Programmmodul aufgebaut wird.

    Doch ich musste letztens eine sehr unangenehme Erfahrung beim Kunden machen. Dieser sieht zwar, dass wir mit dem jetzt erreichten Ergebnis eine deutliche Effizienzverbesserung bei der Entwicklung erreicht haben, doch drängt nun auf die "Produktion" der Software. Bis Jahresende soll ein Teilbereich möglichst weit abgeschlossen sein und die Weiterentwicklung des Generators ist untersagt worden. Er wird nun as-is eingesetzt, von notwendigen Anpassungen mal abgesehen.

    Im Grunde macht man den gleichen Fehler wie zuvor auch. Man fühlt sich künstlich unter Erfolgsdruck und hat lieber kurzfristige Ergebnisse statt mittelfristig eine bessere Effizienz und Qualität. Man ist also wieder zum "Hacken verdammt".

    Ich frage mich ernsthaft, warum Kunden immer noch so denken? Wenn man doch offensichtlich in der Vergangenheit gesehen hat, dass Code-Hacking unter Dauer-Druck nur dazu führt, dass die Fertigstellung sich deutlich verzögert, nicht zuletzt aufgrund der dadurch entstandenen Qualität, warum lernt man nicht daraus?

    Uns wird nichts anderes übrig bleiben als MDSD noch "sanfter" einzuführen und den Generator als "U-Boot-Projekt" weiter zu entwickeln.

    Viele Grüße,
    Karsten
    • 17 Nov 2005, 10:51 pm
  • Mike Wendler
    Mike Wendler
    The company name is only visible to registered members.
    Re^2: "Sanfte" Einführung von MDSD
    Hallo hallo,

    haetten Sie moeglicherweise auch eine Empfehlung fuer ein tool, mit dem man mit moeglichst geringem Finanz- und Zeitaufwand zu guten Ergebnissen kommt?

    Vielen Dank und viele Gruesse, Mike Wendler
    • 02 Mar 2006, 8:21 pm
  • Boris Holzer
    Boris Holzer    Premium Member
    The company name is only visible to registered members.
    Re^3: "Sanfte" Einführung von MDSD
    Hallo,

    2 gute & freie tools sind
    openArchitectureWare (oAW) ---> http://openarchitectureware.org/
    und
    AndroMDA http://www.andromda.org/

    oaw definiert sich als "tool for building MDSD/MDA tools", während andromda sich als "fertiger" generator beschreibt, der allerdings mit mehren cartridges für "Spring, EJB, .NET, Hibernate, Struts and even more" daher kommt (Ist das dann nicht eigentlich CASE statt MDSD ?)

    Beim Austausch mit gewöhnlich gut informierten Kreisen überwiegt aus meiner Sicht die Meinung, dass man mit AndroMDA etwas schneller produktiv ist, aber recht schnell an die Grenzen des Machbaren stößt.

    Mein persönlicher Favorit ist oAW, vor allem das neue 4er Release ist ziemlich cool und "umgänglich" und gut dokumentiert . Zudem gibt es eine gute Eclipse-Integration + Unterstützung des Eclipse Modelling Frameworks.

    Ich hoffe, das hilft !

    Gruß
    Boris
    This post was modified on 03 Mar 2006 at 11:07 am.
    • 03 Mar 2006, 10:59 am
  • Karsten Thoms
    Karsten Thoms
    The company name is only visible to registered members.
    Re^4: "Sanfte" Einführung von MDSD
    Aufgrund des aktuellen Eintrags und meines ursprünglichen Beitrags macht es wohl Sinn mal ein Update zu geben. Ich hatte ja davon berichtet, dass man in meinem Projekt eigentlich nicht wünschte, weiteren Aufwand in die Generator Entwicklung zu stecken. Die Realität hat uns eingeholt.

    Die Effizienzsteigerung durch den Generator ist so "dramatisch" gewesen, dass die aktuelle Entwicklung quasi synchron zur Entwicklung des Fachkonzepts läuft und manchmal sogar Wartezeiten bei der Entwicklung entstanden. Das "dumme" drauf los programmieren konnte nicht umgesetzt werden, weil es eben nicht genug gab. So konnten die Zeiten für die verbesserte Unterstützung durch den Generator genutzt werden.

    Unser Projekt passt eigentlich voll in das Thema dieses Threads, denn hier findet wirklich eine sanfte Einführung von MDSD durch schrittweisen Ausbau der DSL und des Generators statt.

    Um mal Boris' Eintrag aufzugreifen: Uns hätte im "real life" hier keine der Cartridges genutzt, die AndroMDA mitbringt, weil das verwendete Framework hier doch sehr speziell ist. Uns blieb nichts anderes übrig, als die Templates ganz speziell auf unsere Bedürfnisse anzupassen und ein eigenes Metamodell zu implementieren.

    Wir setzen dabei auf openArchitectureWare 3; das Aufsetzen einer Projektumgebung für oAW3 ist zugegebenermaßen etwas müßig, wenn man dieses Tool nicht kennt. Die Doku war bisher auch unzureichend.

    Das alles ändert sich zum Glück mit openArchitectureWare 4. Die Verwendung ist mittlerweile sehr einfach geworden und es gibt jetzt auch eine ausführliche Dokumentation und Tutorials. oAW4 bietet eine hervorragende Integration in die Eclipse IDE und ist auch kürzlich als Subprojekt von Eclipse.org aufgenommen worden. Diesen guten Eindruck vom 4er Release wurde mir durch die Teilnehmer an den Workshops bestätigt, die ich zum neuen Release bereits veranstaltet habe.

    Um mal auf den Aspekt Zeit- und Finanzaufwand zurück zu kommen: oAW (wie auch AndroMDA) sind OpenSource, das ist schon einmal vorteilhaft. Zur Modellierung wird man i.d.R. UML Tools einsetzen, wobei man für den kommerziellen Einsatz auch etwas Geld auf den Tisch legen muss. Zum Einarbeiten bieten sich die Community Editions von Poseidon oder MagicDraw an, die zunächst für den nicht kommerziellen Einsatz frei sind. Bevorzugen würde ich persönlich MagicDraw. Auch für den kommerziellen Einsatz ist MagicDraw eigentlich eine gute Wahl, denn es bietet das beste Preis/Leistungsverhältnis.

    Zeitaufwand ist sicher ein spannendes Thema, denn MDSD Tools sind doch eine Spur komplexer als XDoclet. Für die grundsätzliche Einarbeitung, dass man irgendetwas aus einem UML Diagramm generiert bekommt und es individuellen Bedürfnissen anpassen kann, reicht ein Tag schon aus. Doch sich wirklich mit MDSD zu beschäftigen und die Tools auszureizen wird ein ständiger Lernprozess bleiben. Dennoch wird man mit dem Einsatz solcher Tools immer schneller sein als ohne.

    Je größer ein Projekt wird, desto mehr Anforderungen an die Tools wird man auch stellen. Hier ist es aus meiner Sicht wichtig, dass man quasi sämtliche Freiheiten hat. Wenn man z.B. der Meinung ist, dass ein UML Modell nicht das geeignete Mittel ist, um seine Software zu beschreiben, dann müssen die Tools in der Lage sein, auch andere Modellbeschreibungen auswertbar zu machen. Das klassische Beispiel sind hier Benutzeroberflächen. Diese lassen sich denkbar schlecht durch UML Diagramme beschreiben, auch wenn es häufig versucht wird. So lässt man diese i.d.R. aus. Es gibt aber auch durchaus Möglichkeiten, um den Aufbau, das Verhalten und die Struktur von Oberflächen zu beschreiben. Dann muss man diese Beschreibungen als Teil seines Softwaremodells verstehen und auch in Code umsetzbar machen.
    • 03 Mar 2006, 12:29 pm
  • Post visible to registered members
  • Matthias Bohlen
    Matthias Bohlen    Premium Member
    The company name is only visible to registered members.
    Re^4: "Sanfte" Einführung von MDSD
    Hallo vom Gründer von andromda.org,

    Boris Holzer schrieb:
    Hallo,
     
    2 gute & freie tools sind openArchitectureWare (oAW) ---> http://openarchitectureware.org/
    und AndroMDA http://www.andromda.org/
    oaw definiert sich als "tool for building MDSD/MDA tools", während andromda sich als "fertiger" generator beschreibt,
    ups - ein weit verbreitetes Missverständnis! AndroMDA beschreibt sich nicht als fertiger Generator, sondern wird oft so beschrieben, das ist ein kleiner Unterschied. Wir haben von Anfang an allen Projekten gesagt: Wenn Ihr den MDA-Hebel richtig ansetzen wollt, schreibt Eure eigenen Cartridges, die Code erzeugen, der genau auf Eure Architektur passt! Wir liefern zusätzlich in der Tat eine Menge sehr produktiver Cartridges als proof-of-concept mit, das ist wahr.

    der allerdings mit mehren cartridges für "Spring, EJB, .NET, Hibernate, Struts and even more" daher kommt (Ist das dann nicht eigentlich CASE statt MDSD ?)
    Nein, 80er-Jahre CASE ist, wenn
    a) das Abstraktionsniveau des Modells nur knapp über dem generierten Sourcecode liegt
    b) man die Tranformationen und Templates für die Codeerzeugung nicht selbst kontrolliert, sondern der Toolhersteller das macht

    Beides trifft auf AndroMDA nicht zu.

    Beim Austausch mit gewöhnlich gut informierten Kreisen überwiegt aus meiner Sicht die Meinung, dass man mit AndroMDA etwas schneller produktiv ist, aber recht schnell an die Grenzen des Machbaren stößt.
    Hmm, das wäre jetzt wirklich mal interessant, wo diese Grenzen liegen sollen. Das Argument habe ich nämlich noch nicht gehört. Meine Kunden sagen immer (auch hier im Brett auf openBC): "AndroMDA hat uns noch nie im Stich gelassen". Für sachdienliche Hinweise bin ich also offen.

    Mein persönlicher Favorit ist oAW, vor allem das neue 4er Release ist ziemlich cool und "umgänglich" und gut dokumentiert . Zudem gibt es eine gute Eclipse-Integration + Unterstützung des Eclipse Modelling Frameworks.
    AndroMDA 3.2 unterstützt inzwischen ebenfalls EMF, wir generieren nun auch Code aus UML 2 Modellen, z.B. aus Rational Software Architect oder anderen EMF-basierten Tools. Ausführliche Dokumentation zu AndroMDA (auch zum Entwicklern eigener Cartridges!) findet man unter http://www.andromda.org , Seminare und Consulting dazu gibt's unter http://www.andromda.com .

    Gruß,
    Matthias Bohlen
    http://www.mbohlen.de/
    • 27 Mar 2006, 11:31 pm
  • Boris Holzer
    Boris Holzer    Premium Member
    The company name is only visible to registered members.
    Re^5: "Sanfte" Einführung von MDSD
    Hallo,

    danke für das Feedback !

    Ich wollte keinen Glaubenskrieg vom Zaun brechen, möchte aber dennoch zu einigen Aussagen Stellung nehmen (s.u.)

    Gruß
    Boris Holzer

    ups - ein weit verbreitetes Missverständnis! AndroMDA beschreibt sich nicht als fertiger Generator, sondern wird oft so beschrieben, das ist ein kleiner Unterschied. Wir haben von Anfang an allen Projekten gesagt: Wenn Ihr den MDA-Hebel richtig ansetzen wollt, schreibt Eure eigenen Cartridges, die Code erzeugen, der genau auf Eure Architektur passt! Wir liefern zusätzlich in der Tat eine Menge sehr produktiver Cartridges als proof-of-concept mit, das ist wahr.
    Oh, ich glaube das Missverständnis ist die Interpretation des Wortes "fertig". Ich meinte fertig="ist ein Generator" im direkten Gegensatz zur "tool for building..."-Darstellung von oAW (Eigendarstellung: "AndroMDA is one of the most powerful Open Source MDA Generators on the planet") .

    Nein, 80er-Jahre CASE ist, wenn
    a) das Abstraktionsniveau des Modells nur knapp über dem generierten Sourcecode liegt
    b) man die Tranformationen und Templates für die Codeerzeugung nicht selbst kontrolliert, sondern der Toolhersteller das macht
     
    Beides trifft auf AndroMDA nicht zu.
    Beides trifft nicht zu, das habe ich auch nicht gemeint. Das CASE-Statement bezieht sich auf die Cartridge-Nutzung "out of the box".

    Hmm, das wäre jetzt wirklich mal interessant, wo diese Grenzen liegen sollen. Das Argument habe ich nämlich noch nicht gehört. Meine Kunden sagen immer (auch hier im Brett auf openBC): "AndroMDA hat uns noch nie im Stich gelassen". Für sachdienliche Hinweise bin ich also offen.
    Da muss ich mich korrigieren:
    Die "Grenzen" - Aussage ist veraltet.
    Danke für den Hinweis !
    • 28 Mar 2006, 10:27 am
  • Peter Friese
    Peter Friese    Premium Member
    The company name is only visible to registered members.
    Re^6: "Sanfte" Einführung von MDSD
    Hallo,

    ups - ein weit verbreitetes Missverständnis! AndroMDA beschreibt sich nicht als fertiger Generator, sondern wird oft so beschrieben, das ist ein kleiner Unterschied. Wir haben von Anfang an allen Projekten gesagt: Wenn Ihr den MDA-Hebel richtig ansetzen wollt, schreibt Eure eigenen Cartridges, die Code erzeugen, der genau auf Eure Architektur passt! Wir liefern zusätzlich in der Tat eine Menge sehr produktiver Cartridges als proof-of-concept mit, das ist wahr.
     
    Oh, ich glaube das Missverständnis ist die Interpretation des Wortes "fertig". Ich meinte fertig="ist ein Generator" im direkten Gegensatz zur "tool for building..."-Darstellung von oAW (Eigendarstellung: "AndroMDA is one of the most powerful Open Source MDA Generators on the planet") .
    Ich glaube auch, dass das Wort "Generator" zu Mißverständnissen führt:

    Im AndroMDA-Universum meinen wir (ich bin AndroMDA Committer) mit "Generator" die Engine eines UML Tools. D.h. der Teil der Software, der die Modelle einliest, und dann (gesteuert durch Stereotype und Tagged Values) die Modellelemente mit Hilfe einer Template Engine transformiert (in Code oder andere Modelle). Die zum Lieferumfang von AndroMDA gehörenden Cartridges sehen wir eigentlich als Add-On. Quasi als Erstausstattung für die Anwender. Wer die Cartridges mag, kann sie direkt einsetzen und ggfls. modifizieren. Wer die Cartridges nicht einsetzen mag / kann (z.B. weil er eine andere Architektur oder andere Sprache einsetzt), der kann / muss sich eben selbst Cartridges schreiben.

    oAW bezeichnet (sofern ich es recht beurteile) immer die Gesamtheit aus Engine und Transformationsregeln als "Generator".

    Beide Denkweisen sind m.E. richtig, führen aber zu den o.g. Mißverständnissen. Vielleicht sollten beide Teams (oAW und AndroMDA) sich auf eine Sprechweise einigen (am besten diejenige, die auch in der Literatur / Forschung verwendet wird), damit die Mißverständnisse ausgeräumt werden können. Dies böte den Vorteil, dass beide Tools besser miteinander verglichen werden können.

    Viele Grüße,
    Peter
    http://f3.tobject.de
    http://www.andromda.org
    • 04 Apr 2006, 9:23 pm
  • Matthias Bohlen
    Matthias Bohlen    Premium Member
    The company name is only visible to registered members.
    Re^7: "Sanfte" Einführung von MDSD

    Peter Friese schrieb:
    Im AndroMDA-Universum meinen wir (ich bin AndroMDA Committer) mit "Generator" die Engine eines UML Tools.
    Hm, nicht ganz - nicht im UML Tool steckt der Generator, sondern in AndroMDA. Doch was Du als Definition bringst, ist richtig: Als "Generator" wird bei uns nur die Engine bezeichnet, nicht die Transformationen und nicht die Templates.

    Gruß
    Matthias
    • 04 Apr 2006, 11:08 pm