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

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

Posts 1-10 of 17
  • Kurt Seebauer
    Kurt Seebauer    Premium Member
    The company name is only visible to registered members.
    MDA und SOA
    Hallo zusammen,

    hier sind einige Gedanken von mir zum Thema MDA und SOA. Ich hoffe, es interessiert den einen oder anderen.

    Model Driven Architecture / Model Driven Software Development ist ein Versuch, die Entwicklung von Software auf ein möglichst hohes Sprachniveau zu heben. Ziel ist es, Sachverhalte durch Modelle so kurz und prägnant wie möglich auszudrücken und jegliche Art von Redundanz bei der Implementierung zu vermeiden. Das ist deshalb notwendig, weil in verbreiteten Frameworks Dinge an mehreren Stellen implementiert werden, beispielsweise das Datenschema als ER-Diagramm, UML-Klassendiagramm und als Hibernate-Mapping. Mit MDA wird nur einmal modelliert, beispielsweise in Form eines UML-Diagramms, das Datenbankschema und das Mapping kann dann automatisch generiert werden. Somit ist die Redundanz von der Implementierungsebene verbannt, Inkonsistenzen sind damit ausgeschlossen. Entwicklungszeit wurde auch noch gespart, denn der CRUD-Code ist auf diese Weise "von selbst" entstanden. Werkzeuge für diese Art von "Programmierung" sind beispielsweise androMDA mit der entsprechenden Cartridge oder openArchitectureWare, welches ohne Cartridges, dafür mit höherer Flexibilität kommt.

    Service Oriented Architecture geht das Problem auf eine andere Weise an. Wie im Forum schon gesagt wurde, gibt es keine Definition, auf welcher Granularitätsebene sich die "Services" befinden. Theoretisch kann man alles von Methoden bis Webservice als "Service" bezeichnen. Das softwaretechnische Prinzip, zusammengehörige Dinge zu kapseln und über eine definierte Schnittstelle zugänglich zu machen, gibt es schon lange. Als aktive Services, denen man "Fragen stellen" kann, oder als passive Bibliotheken oder Objekte, die man benutzt.

    In unserem Datenschema-Beispiel hätte man die Redundanz der Implementierung nicht nur durch Codegenerierung verschwinden lassen können, sondern auch durch Kapselung. Das Active Record-Pattern, wie es aus Ruby on Rails bekannt ist, mappt ohne großen Konfigurationsaufwand Klassen auf Tabellen. Für .NET gibt es das noch recht unbekannte Castle Project ( http://www.castleproject.org ). Modelliert wird das Datenschema in Form von annotierten (.NET: "attributierten") Entities. Sprich, mal sagt der Klasse in Form einer Anmerkung, auf welche Tabelle sie mappt und jedem Property, welche Spalte zuständig ist. Um den Rest braucht man sich nicht kümmern.

    In einer kleine Beispielanwendung mit 12 Entity-Klassen erzeugte die androMDA-Cartridge für NHibernate/Spring für den CRUD-Code 8960 Zeilen C#, wobei die lästige Redundanz auf Codeebene noch vorhanden ist. Die Active-Record-Beans für Castle brauchen 1279 Zeilen annotiertes C#, die Redundanz ist komplett aus den Augen des Programmierers verschwunden. Mit Castle hat man eine Abhängigkeit auf ein paar Bibliotheken in sein Projekt hinzugefügt, mit androMDA eine Abhängigkeit auf ein Modellierungstool (magicDraw), den Generator und die Cartridges. Eine Neugenerierung des Projektes bei Änderungen am Modell ist mit androMDA zwar möglich (daher auch die recht komplizierte Klassenstruktur mit sechs Dateien für jedes Bean), funktioniert aber nicht immer fehlerfrei. Die von MagicDraw erzeugte XMI-Repräsentation des Modells beinhaltete in meinen Versuchen plötzlich namenlose Klassen, die den Generator und mich zur Verzweiflung trieben. Die XMI-Datei ist für das Dutzend Entities so riesig, so dass die manuelle Fehlersuche ziemlich anstrengend wurde. Alles in allem ein recht fragiler und aufreibender Entwicklungsprozess.

    Mein Fazit für diesen Versuch: MDA sollte nicht dazu verwendet werden, um Mängel in den verwendeten Frameworks totzuschlagen. Die primäre Arbeitsumgebung des Programmierers ist immer noch der Code, nicht das Modellierungstool. Ruby on Rails und das Castle-Projekt zeigen, dass Redundanz auf Codeebene nicht notwendig sind. Und wo keine Redundanz ist, kann kein Generator "den dummen Code" generieren. An irgendeiner Stelle muss das System sauber spezifiziert werden. An _genau_einer_. Ob die Stelle im Code oder im Modell ist, entscheidet die Reife und der Integrationsgrad der Modellierungstools. MagicDraw ist nicht die Lösung. Eine gut in die IDE integrierte Lösung vielleicht schon.

    Neben androMDA gibt es auf dem Markt noch andere MDA/MDSD-Tools. OpenArchitectureWare wurde bereits erwähnt. Es glänzt mit einer sehr guten Eclipse-Integration und großer Flexibilität. Es kann UML-Modelle in Code umwandeln, wie androMDA. Außerdem ist es möglich, eigene domänenspezifische Sprachen zu kreieren und zu benutzen. Dazu stehen eine Menge von Hilfsmitteln und Sprachen zur Verfügung, deren Vielfalt mich gleich davon abgehalten haben, das Ding überhaupt auszuprobieren ;-). Die Verwechslungsgefahr der xtend-, xpand- uns xtext-Dateien sofort erkennend, hab ich mir lieber die Screencasts angeschaut, die recht anschaulich den Bau eines eigenen Generators vorführen. Mir will nicht ganz in den Kopf, weshalb ich eine eigene DSL basteln soll, wenn es UML auch tut. Die Dokumentation von openArchitectureWare scheint recht umfassend zu sein, einen leichten Einstieg fand ich aber trotzdem nicht. Ich vermisse einen einfachen Überblick, was man mit dem Werkzeug alles tun kann, wieso man eine DSL schreiben sollte und welches Dateiformat welchen Zweck erfüllt.

    Das dritte MDA-Werkzeug mit Marktrelevanz sind Microsofts DSL-Tools. Meiner unzuverlässigen Erinnerung nach wurde es hier im Forum noch gar nicht erwähnt. Ok, es ist ein absoluter newcomer und gehört zu Microsofts proprietärer Entwicklungsumgebung. Die DSL-Tools erlauben die Entwicklung einer grafischen DSL in Visual Studio. Es scheint also recht gut mit openArchitectureWare vergleichbar zu sein. Wiederum fällt mir kein überzeugender Grund ein, warum es ein DSL-Werkzeug sein muss, wenn ein gutes UML-Tool doch mindestens genauso sinnvoll gewesen wäre. Die Beispiel-DSLs, die ich gesehen haben, hatten alle große Ähnlichkeit mit einem UML-Klassendiagramm. Und um Klassendiagramme zu zeichnen, brauche ich doch keine DSL. Als Anwendungszweck für eine DSL fallen mir Workflows ein, die mit UML nicht so leicht darstellbar sind. Wobei sich hier die Frage stellt, ob für so einen verbreiteten Anwendungsfall nicht eine Modellierungsmöglichkeit für UML fällig wäre?

    Zusammenfassend würde ich sagen, das SOA und MDA Technologien sind, die sich ergänzen und auf einem Überschneidungsgebiet konkurrieren. Wo es möglich ist, sollte meiner Meinung nach der SOA-Ansatz der gekapselten, wiederverwendbaren Einheit bevorzugt werden.

    Wer von Ihnen hat Erfahrung mit selbstgeschriebenen DSLs gemacht? Für welche Zwecke wurden sie eingesetzt und wie sahen sie aus? Konnte UML nicht benutzt werden? Wer setzt Codegeneratoren ein, um Redundanz von der Modell- auf die Codeebene zu drücken? Wer lehnt MDA komplett ab?

    Über viele Kommentare würde ich mich sehr freuen!

    Viele Grüße,
    Kurt Seebauer
    • 01 Dec 2006, 10:10 am
  • Michael Kunz
    Michael Kunz    Premium Member
    The company name is only visible to registered members.
    Re: MDA und SOA
    Hallo Hr. Seebauer,
    beiliegend einige Anmerkungen zu Ihren interessanten Ausführungen:

    >Model Driven Architecture / Model Driven Software Development ist ein Versuch, die Entwicklung von Software >auf ein möglichst hohes Sprachniveau zu heben.
    Nun ja: Möglichst hoch könnte den einen oder anderen "überfordern", angemessen hoch würde ich daher als Formulierung vorziehen (Sprich: Modelle, die (fast) niemand mehr versteht, schaden und nützen nicht) . Und angemessen hoch kann sehr situationsabhängig sein...

    >Ziel ist es, Sachverhalte durch Modelle so kurz und prägnant wie möglich auszudrücken und jegliche Art von
    >Redundanz bei der Implementierung zu vermeiden. Das ist deshalb notwendig, weil in verbreiteten Frameworks >Dinge an mehreren Stellen implementiert werden, beispielsweise das Datenschema als ER-Diagramm, UML->Klassendiagramm und als Hibernate-Mapping. Mit MDA wird nur einmal modelliert, beispielsweise in Form >eines UML-Diagramms, das Datenbankschema und das Mapping kann dann automatisch generiert werden. >Somit ist die Redundanz von der Implementierungsebene verbannt, Inkonsistenzen sind damit ausgeschlossen. >Entwicklungszeit wurde auch noch gespart, denn der CRUD-Code ist auf diese Weise "von selbst" entstanden. >Werkzeuge für diese Art von "Programmierung" sind beispielsweise androMDA mit der entsprechenden >Cartridge oder openArchitectureWare, welches ohne Cartridges, dafür mit höherer Flexibilität kommt.
    Diese Sicht ist meiner Meinung nach sehr eindimensional: MDA/MDSD hat viele Facetten und Auswirkungen. Eine sehr wichtige weitere (neben vielen hier nicht aufgeführten) ist ABSTRAKTION: Ich habe schon eine Reihe von realen Beispielen gesehen, wo Fachlichkeit auch bei späterem Austausch der technischen Basis ganz oder in wesentlichen Teilen gerettet wurde (und Technologien ändern sich leider öfters, als man es bei der Erstellung eines Systems anfänglich denkt). Das kann SOA nur für einen sehr eingeschränkten Bereich - und ob es dort genauso gut funktioniert, wird die Zukunft erst noch beweisen müssen - da könnte man gewisse Zweifel haben.

    >In unserem Datenschema-Beispiel hätte man die Redundanz der Implementierung nicht nur durch >Codegenerierung verschwinden lassen können, sondern auch durch Kapselung. Das Active Record-Pattern, wie >es aus Ruby on Rails bekannt ist, mappt ohne großen Konfigurationsaufwand Klassen auf Tabellen. Für .NET gibt >es das noch recht unbekannte Castle Project ( http://www.castleproject.org ). Modelliert wird das Datenschema in >Form von annotierten (.NET: "attributierten") Entities. Sprich, mal sagt der Klasse in Form einer Anmerkung, auf >welche Tabelle sie mappt und jedem Property, welche Spalte zuständig ist. Um den Rest braucht man sich nicht >kümmern.
    Und was machen Sie, wenn Ihr Lieblingsframework von heute nicht mehr Ihr Lieblingsframework von morgen ist?

    >In einer kleine Beispielanwendung mit 12 Entity-Klassen erzeugte die androMDA-Cartridge für NHibernate/Spring >für den CRUD-Code 8960 Zeilen C#, wobei die lästige Redundanz auf Codeebene noch vorhanden ist.
    (Genrierte) Redundanzen auf Implementierungsebene haben Sie nicht zu interessieren - sonst stimmt etwas mit Ihrem MDSD-Tool oder Ihrer generativen Architektur nicht...

    >Die Active-Record-Beans für Castle brauchen 1279 Zeilen annotiertes C#, die Redundanz ist komplett aus den >Augen des Programmierers verschwunden. Mit Castle hat man eine Abhängigkeit auf ein paar Bibliotheken in >sein Projekt hinzugefügt, mit androMDA eine Abhängigkeit auf ein Modellierungstool (magicDraw), den >Generator und die Cartridges. Eine Neugenerierung des Projektes bei Änderungen am Modell ist mit androMDA >zwar möglich (daher auch die recht komplizierte Klassenstruktur mit sechs Dateien für jedes Bean), funktioniert >aber nicht immer fehlerfrei. Die von MagicDraw erzeugte XMI-Repräsentation des Modells beinhaltete in meinen >Versuchen plötzlich namenlose Klassen, die den Generator und mich zur Verzweiflung trieben. Die XMI-Datei ist >für das Dutzend Entities so riesig, so dass die manuelle Fehlersuche ziemlich anstrengend wurde. Alles in allem >ein recht fragiler und aufreibender Entwicklungsprozess.
    Siehe oben, allerdings kann das herumexperimentieren mit Tools am Anfang etwas auf die Nerven gehen. Da sollte man jemanden fragen, der schon Erfahrung hat. MDSD/MDA im Alleingang ist zugegebenermaßen relativ aussichtslos..

    >Mein Fazit für diesen Versuch: MDA sollte nicht dazu verwendet werden, um Mängel in den verwendeten >Frameworks totzuschlagen. Die primäre Arbeitsumgebung des Programmierers ist immer noch der Code, nicht >das Modellierungstool. Ruby on Rails und das Castle-Projekt zeigen, dass Redundanz auf Codeebene nicht >notwendig sind. Und wo keine Redundanz ist, kann kein Generator "den dummen Code" generieren. An >irgendeiner Stelle muss das System sauber spezifiziert werden. An _genau_einer_. Ob die Stelle im Code oder >im Modell ist, entscheidet die Reife und der Integrationsgrad der Modellierungstools. MagicDraw ist nicht die >Lösung. Eine gut in die IDE integrierte Lösung vielleicht schon.
    Für ein einzelnes Framework mag das stimmen, leider sind Architekturen in der Regel so hinterhältig, sich aus mehreren sich gegenseitig nicht kennenden Teilen zusammenzusetzen. Irgendwoher muß mindestens der Glue kommen...

    >Neben androMDA gibt es auf dem Markt noch andere MDA/MDSD-Tools. OpenArchitectureWare wurde bereits >erwähnt. Es glänzt mit einer sehr guten Eclipse-Integration und großer Flexibilität. Es kann UML-Modelle in Code >umwandeln, wie androMDA. Außerdem ist es möglich, eigene domänenspezifische Sprachen zu kreieren und >zu benutzen. Dazu stehen eine Menge von Hilfsmitteln und Sprachen zur Verfügung, deren Vielfalt mich gleich >davon abgehalten haben, das Ding überhaupt auszuprobieren ;-). Die Verwechslungsgefahr der xtend-, xpand- >uns xtext-Dateien sofort erkennend, hab ich mir lieber die Screencasts angeschaut, die recht anschaulich den >Bau eines eigenen Generators vorführen. Mir will nicht ganz in den Kopf, weshalb ich eine eigene DSL basteln >soll, wenn es UML auch tut. Die Dokumentation von openArchitectureWare scheint recht umfassend zu sein, >einen leichten Einstieg fand ich aber trotzdem nicht. Ich vermisse einen einfachen Überblick, was man mit dem >Werkzeug alles tun kann, wieso man eine DSL schreiben sollte und welches Dateiformat welchen Zweck erfüllt.
    Zu Tools sollte man erst nach Beschäftigung mit den zu Grunde liegenden Konzepten greifen. So etwas wird in einschlägigen Artikel oder Büchern wie z. B. "Modellgetriebene Softwareentwicklung" von Stahl/Völter erläutert.

    >Das dritte MDA-Werkzeug mit Marktrelevanz sind Microsofts DSL-Tools. Meiner unzuverlässigen Erinnerung >nach wurde es hier im Forum noch gar nicht erwähnt. Ok, es ist ein absoluter newcomer und gehört zu Microsofts >proprietärer Entwicklungsumgebung. Die DSL-Tools erlauben die Entwicklung einer grafischen DSL in Visual >Studio. Es scheint also recht gut mit openArchitectureWare vergleichbar zu sein. Wiederum fällt mir kein >überzeugender Grund ein, warum es ein DSL-Werkzeug sein muss, wenn ein gutes UML-Tool doch mindestens >genauso sinnvoll gewesen wäre. Die Beispiel-DSLs, die ich gesehen haben, hatten alle große Ähnlichkeit mit >einem UML-Klassendiagramm. Und um Klassendiagramme zu zeichnen, brauche ich doch keine DSL. Als >Anwendungszweck für eine DSL fallen mir Workflows ein, die mit UML nicht so leicht darstellbar sind. Wobei sich >hier die Frage stellt, ob für so einen verbreiteten Anwendungsfall nicht eine Modellierungsmöglichkeit für UML >fällig wäre?
    Faustregel: UML eignet sich nur für einige wenige, relativ einfache Aufgabenstellungen (Abläufe, Beschreibung von Strukturen mittels Klassendiagrammen usw.). So etwas für komplexere Zusammenhänge einzusetzen, wird schnell sehr unübersichtlich, wenn es überhaupt gelingt. Wir haben das mal für die modellgetriebene Beschreibung von Testfällen versucht (http://www.mdtd.de/technik.html), das war definitv n i c h t praktikabel auf UML-Basis.

    >Zusammenfassend würde ich sagen, das SOA und MDA Technologien sind, die sich ergänzen und auf einem >Überschneidungsgebiet konkurrieren. Wo es möglich ist, sollte meiner Meinung nach der SOA-Ansatz der >gekapselten, wiederverwendbaren Einheit bevorzugt werden.
    Ich bin in beiden Welten (SOA und MDA/MDS) tätig, bin aber zusammen mit anderen der Meinung, daß SOA ohne MDSD/MDA in der Regel keinen Sinn ergibt und im übrigen MDSD das allgemeinere Konzept ist. Dazu gibt es in diesem Forum auch einen anderen Thread, den möchte ich hier nicht wiederholen...

    >Wer von Ihnen hat Erfahrung mit selbstgeschriebenen DSLs gemacht? Für welche Zwecke wurden sie eingesetzt >und wie sahen sie aus? Konnte UML nicht benutzt werden? Wer setzt Codegeneratoren ein, um Redundanz von >der Modell- auf die Codeebene zu drücken? Wer lehnt MDA komplett ab?
    Z. B. im Bereich Test: s. http://www.mdtd.de

    In der Hoffnung auf eine weitere spannende Diskussion
    Michael Kunz
    This post was modified on 03 Dec 2006 at 08:43 am.
    • 01 Dec 2006, 6:59 pm
  • Thomas Kilian
    Thomas Kilian    Premium Member
    The company name is only visible to registered members.
    Re^2: MDA und SOA
    Hallo Herr Kunz,
    kurz gesagt: gut gebrüllt, Löwe.

    Meine Erfahrung mit MDA deckt sich da im wesentlichen. Ergänzend noch folgende Feststellung: Wenn man sich auf einer grünen Wiese befindet, dann ist MDA sicher eine tolle Sache (so man denn das Tool und die einhergehende Methodologie mag). Wenn man aber, was eigentlich immer der Fall ist, mal von der Schiene runter muss, weil es da so häßliche Erbschaften (zu Neudeutsch Legacy-Systeme) gibt, dann nützt der ganze Vorteil rein gar nix und gerät eher zum Nachteil. Für mich ist die Frage MDA oder nicht gleichbedeutend mit der Frage, ob die Grüne Wiese in Hektar oder Quadratemeter gemessen wird.

    So sehr spannend ich den Ansatz MDA auch finde, ist er für die meisten Anwendungen doch eher eine Totgeburt. Die "lebhaften" Diskussionen in diesem Forum lassen mich schließen, dass es in der Praxis eher weniger als mehr Anwendungsfälle gibt.

    Gruß, Thomas Kilian
    • 01 Dec 2006, 9:56 pm
  • Post visible to registered members
  • Karsten Thoms
    Karsten Thoms
    The company name is only visible to registered members.
    Re^3: MDA und SOA
    Sehr geehrter Herr Kilian,

    MD* und Legacy-Systeme schließen sich nicht aus, sondern ergänzen sich ganz gut. Auch bei Legacy-Systemen wird man durch Abstraktion zu modellierbaren Konzepten kommen, die ein Generator verstehen kann und für weitere Umsetzungen zumindest teilweise automatisiert. Man darf dann eben nicht gleich an UML und an Generatoren denken, die nur UML "verstehen", denn wie Herr Kunz schon richtig aufgeführt hat wird man mit der UML auch mal an Grenzen stoßen. Was natürlich nicht heißt, dass die UML keinen Sinn macht.

    Gerade auch deswegen gibt es DSLs und Tools wie openArchitectureWare. Legacy Systeme sind ein gutes Beispiel dafür, dass man bei der Gestaltung von Modellen ganz spezifische Sprachen (eben eine DSL) und den verarbeitenden Generatoren vollkommene Flexibilität benötigt. Es gibt natürlich keine General Purpose Sprache für ein spezielles Legacy System und damit kann es auch keine fertige Cartridge für einen Generator geben. Es ist daher wichtig, dass die Erstellung und Pflege von spezialisierten DSLs und Generator Cartidges möglichst einfach sein muss.

    Genau das ist auch eine Motivation hinter dem openArchitectureWare Projekt. Es bietet die nötige Flexibilität und ermöglicht die Anbindung beliebiger DSLs (auf Basis EMF, UML1, UML2, JavaBeans, XML, etc.). Es ist auch nicht nötig, dass es genau ein Modell auf Basis eines Metamodells gibt, sondern es können auch beliebige Modelle "verwebt" werden. Damit ist es auch möglich, unterschiedliche Modelle für die verschiedenen Aspekte eines Softwaresystems zu verwenden.

    Natürlich bleibt es nicht aus, dass man sich eingehend mit der Thematik auseinandersetzen muss, um die Möglichkeiten dieses Ansatzes sinnvoll nutzen zu können. Wer einen Auf-Knopfdruck-Die-Fertige-Anwendung Generator sucht ist mit openArchitectureWare sicherlich an der falschen Adresse. Die einfachsten Tutorials bieten genau das, aber man kommt damit nicht weit. Es entstehen auch eine ganze Reihe von Standard-Cartridges für Standard-Problemstellungen (EJB, Spring, Hibernate etc., u.a. http://www.fornax-platform.org), die natürlich nützlich sind, solange man dieses Standard-Problem zumindest im Teil hat. (Man kann natürlich beliebige Cartridges integrieren).

    Wer "richtige" Anwendungen modellgetrieben erstellt (das bedeutet auch Integration von Legacy-Systemen), der wird schnell erkennen, dass er mit openArchitectureWare auf das richtige Pferd setzt. Es ist mit Einarbeitung und Erfahrung verbunden, aber das trifft auf jede ernstzunehmende Technologie zu. Unter dem Strich gewinnt man durch modellgetriebene Entwicklung (vor allem Qualität, Zeit und damit Geld - unabhängig von der Toolkette), da gibt es bereits umfassende Erfahrung zu.

    Beste Grüße,
    ~Karsten Thoms
    • 07 Dec 2006, 09:56 am
  • Post visible to registered members
  • Thomas Kilian
    Thomas Kilian    Premium Member
    The company name is only visible to registered members.
    Re^4: MDA und SOA
    Hallo allerseits,
    sorry, aber ich war einige Zeit anderweitig beschäftigt. Ich bin aber sehr erfreut, dass es gleich mehrere Rückmeldungen gegeben hat.

    Ich versuche mal, eine Rundum-Antwort zu geben. Das Problem welches ich beim Einsatz von MDA sehe, ist die Tatsache, dass man ein bestimmtes Gleis einschlägt und dieses auch fahren muss. Konkret sieht es doch so aus, dass die mehr oder weniger abstrakten Geschäftsklassen in konkrete Ausprägungen anhand des MVC Paradigmas ausgeprägt werden. Das ist natürlich wunderbar, weil man sich um recht wenig kümmern muss. Die Bildschirme werden generiert, die Tabellen in der Datenbank samt Zugriffsklassen automatisch erzeugt und meist gibt es als Bonbon auch noch den einen oder anderen Control oder zuwenigst einen einfach anpassbaren Rahmen. Leider haben aber die (sogenannten) Legacy-Anwendungen (welche nicht unbedingt Host-basisert sein müssen) den Nachteil, dass sie über keine oder nur sehr "merkwürdige" Schnittstellen verfügen. Man muss also anfangen, selbst eine Schnittstelle in Form eines Wrappers zu konstruieren. Wer das schon einmal bei "wohlgeformten" Systemen gemacht hat (die ja i.A. auch nicht orthogonal operieren), der weiß, was Fluchen bedeutet. Ich lasse mich hier gern eines Besseren belehren, aber mir ist noch kein System untergekommen, an dass ich etwas anflanschen konnte, ohne mir mindestens eine Gehirnwindung zu verbiegen. Ein MDA-System entsprechend mit einem Interface anzukoppeln ist aus meiner Sicht heraus der Versuch, eine Steckdose mit einem Wasserhahn zu koppeln.

    Herr Röttgers, können Sie vielleicht ein konkretes Beispiel geben, bei der MDA und Legacy sinnvoll kombiniert wurden?
    • 13 Dec 2006, 9:13 pm
  • Post visible to registered members
  • Kurt Seebauer
    Kurt Seebauer    Premium Member
    The company name is only visible to registered members.
    Re^6: MDA und SOA
    Hallo zusammen,

    erstmal vielen Dank für die rege Diskussionsbeteiligung und die interessanten Beiträge!

    Ich sehe noch einige Unklarheiten bei den Begriffen. Ersteinmal MDA, darunter versteht man nach Lehrmeinung der OMG die Modellierung mit UML und anschließende Generierung der Software. So funktioniert im Wesentlichen auch androMDA, und so fasst wohl auch Herr Kilian die Sache auf? Ein Schwenk auf MDA im laufenden Projekt bzw. unter Einbindung vorhandener ist damit natürlich sehr schwierig. Eine Portierung eines vorhandenen Produktes auf MDA geht wohl auch nicht. Wir vergessen hier wohl allzuschnell, dass Softwareentwicklung nicht nur in Projekten abläuft, sondern auch ganz normale Produkte jahr(zehnt)elang fortentwickelt werden.

    Demgegenüber steht der MDSD-Ansatz, der schon vor der neuen Mode unter dem Namen "generative Programmierung" bekannt und beliebt war. Lex und Yacc als DSLs zum Compilerbau fallen mir ein. Das erste "Pragmatic Programmer"-Buch von 1999 setzt sich stark für generative Programmierung ein. Von MDSD/MDA war da noch nicht die Rede. In diese Kategorie passt openArchitectureWare sehr gut. DSLs sind beliebig definierbar, auch wenn auch MDA genau wie mit androMDA möglich ist. Damit sollte auch eine Einbindung von Altsystemen gut möglich sein. Man braucht nur definierte Schnittstellen und gute Kapselung. Womit wir wieder bei der SOA wären.

    Herr Kunz: Abstraktion ist ein gutes Stichwort, das habe ich bei meiner Fixierung auf Redundanzvermeidung übersehen. Ob wir aber jemals soweit kommen, dass man eine Anwendung plattformunabhängig modellieren können, ist fraglich. Mein Beispiel mit androMDA wäre sicherlich auch sofort unter JEE lauffähig gewesen, zumindest die generierten Teile. Es gibt halt Hibernate/Spring sowohl für Java als auch .NET. Ansonsten haben die Plattformen aber so gravierende Unterschiede und einen derartigen Umfang, dass ich mich frage, wie die Cartridges da aussehen müssten...

    Ich hab noch ein Unterscheidungsmerkmal zwischen MD* und SOA gefunden: Wird der Code dynamisch oder statisch generiert? Während mein androMDA-Beispiel den Code statisch erzeugt hat, benutzte Castle dynamische Mechanismen. Das war es, was mir den MDA-Ansatz etwas unsympathisch machte. Ich behaupte pauschal, dass die Lösung, die mit dem wenigsten (statischen) Code auskommt, die bessere ist. Deswegen hat Castle hier klar gewonnen. Wo eine dynamische Alternative nicht vorhanden ist, mag MDSD die richtige Lösung sein.

    Viele Grüße,
    Kurt Seebauer
    • 14 Dec 2006, 12:29 pm
  • Thomas Kilian
    Thomas Kilian    Premium Member
    The company name is only visible to registered members.
    Re^7: MDA und SOA
    Hallo Herr Hybel,
    Ihre Frage zur Begriffsklärung ist durch Hrn. Seebauer hinreichend und korrekt beantwortet. Zu den Legacysystemen: Im Prinzip verstehe ich darunter jegliches System, welches abgelöst werden soll. Da man üblicherweise keine gut funktionierenden System ablöst, sondern dazu meist ein zwingender Grund vorliegt, betrachte ich diese generell als "Legacy" (Erbschaft bedeutet ja vorwiegend, dass jemand tot ist und nur sekundär, dass es auch etwas wertvolles zu erben gibt).

    Wie schon oben geschrieben, würde mich dennoch interessieren, ob es einigermaßen reibungslose Projekte gab, in denen mit MDA ein Altsystem abgelöst wurde. Und natürlich welche positiven und negativen Wendungen diese Projekte genommen haben.

    Gruß, Thomas Kilian
    This post was modified on 15 Dec 2006 at 04:20 pm.
    • 15 Dec 2006, 4:20 pm