MDA, alter Wein in neuen Schläuchen oder Weg für die Zukunft?
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Guido Zockoll
Copyright © 2005
Inhaltsverzeichnis
Einleitung .................................................................................................................. 1
Ein Blick zurück ......................................................................................................... 1
Und in Zukunft? ......................................................................................................... 2
Modell Driven Architecture .......................................................................................... 2
Die Wurzel allen Übels ................................................................................................ 3
Alter Wein in neuen Schläuchen .................................................................................... 4
Ausgangslage ............................................................................................................. 5
Investitionssicherheit ................................................................................................... 6
Grenzen .................................................................................................................... 7
Ausblick .................................................................................................................... 7
Literatur & Links ........................................................................................................ 7
Einleitung
Seit einiger Zeit ließt man in der einschlägigen Fachpresse zunehmend mehr über modellgetriebene
Softwareentwicklung, kurz MDA (Model Driven Architecture)1 und seine Verwandten. Nun sind
Programmgeneratoren kein neuer Gedanke, so stellt sich natürlich die Frage, was an MDA so anders
oder gar neu sein soll gegenüber den Ansätzen der letzten 20 Jahre.
Ein Blick zurück
In den Anfängen der Informatik wurden Programme in Assembler geschrieben. Jeder Prozessor hatte
natürlich seine eigene Assemblersprache, Portabilität war nicht gegen. Ein paar Jahre später tauchen die
ersten Compiler-Sprachen wie z.B. C auf. Die ersten Compiler generierten aus den Quelltexten zunächst
Assembler Code, der dann wie gewohnt in Maschinen-Code übersetzt wurde. Diesen Zwischencode
konnte man sich ansehen um die Qualität des erzeugten Codes zu überprüfen und ggf. durch Hinweise
wie register eine Optimierung vorzunehmen. Der Quelltext war damit über verschiedene
Rechnerarchitekturen zumindest theoretisch portabel.
Ein paar Jahre später kamen objektorientierte Programmiersprachen in Mode. Die ersten C++ Compiler
waren in der Tat Precompiler, die zunächst C Code erzeugt haben, der dann über weitere
Zwischenschritte übersetzt wurde. Dieser Zwischenschritt fiel kurz darauf weg und der Compiler hat
mehr oder weniger direkt Maschinen-Code erzeugt.
Wieder ein paar Jahre später kamen die ersten UML Case-Tools auf den Markt. Auf Basis von UML-
Diagrammen können diese Werkzeuge u.a. C++ Code erzeugen.
1vgl. [MDA04 ]
1MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Abbildung 1. Sprachen in der Softwareentwicklung
Und in Zukunft?
Aus der historischen Betrachtung ergibt sich die logische Frage, aus was in den nächsten Jahren die
UML-Diagramme generiert werden. So ungewöhnlich diese Frage erscheint, so liegt darin doch die
logische Konsequenz aus der Entwicklung in den vergangenen Jahren. Die Antwort der OMG auf diese
Frage lautet: "Aus anderen, abstrakteren UML-Diagrammen".
Modell Driven Architecture
Der Grundgedanke der MDA ist, sich in der Modellierung auf die rein fachlichen Aspekte zu
beschränken und insb. keine technischen Aspekte zu modellieren. Dadurch entsteht zunächst das sog.
"Plattform independent model", kurz PIM. Daraus lassen sich dann durch Transformation andere
Modelle generieren, die eine Umsetzung auf einer konkreten Plattform darstellen.
Abbildung 2. MDA Transformationsprozess
2MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Der Begriff Plattform ist dabei sehr allgemein gehalten und gilt sowohl für die benutzte Hardware, als
auch für die Programmiersprache und evtl. eingesetzte Frameworks. So lässt sich dann aus dem PIM ein
"plattform specific model", kurz PSM, generieren, das eine Realisierung z.B. mittels Java und dem J2EE
Framework darstellt.
MDA und andere
Inzwischen tauchen auch andere Abkürzungen wie MDD (Modell Driven Design) oder DDD (Domain
Driven Design) auf, die schon von der Begrifflichkeit nur schwer auseinander zu halten sind. Der
Grundgedanke der OMG ist, dass als Ausgangssprache für die Generierung UML dient, wobei die OCL
(Object Constraint Language), die ebenfalls Bestandteil der UML Spezifikation ist, mit eingeschlossen ist.
Angestrebt wird ein weitgehendes Forward-Engeneering, d.h. dass möglichst viel Programmcode direkt
aus Modellen generiert wird.
Im Gegensatz dazu stellt MDD einen eher pragmatischen Ansatz dar. Zum Einen dient nicht nur die UML
als Ausgangssprache, sondern auch andere Beschreibungssprachen werden berücksichtigt. So ist es z.B.
denkbar, Bildschirmmasken in einer eigenen XML Spezifikationssprache zu beschreiben und daraus
entsprechende Programmdateien zu generieren. Auf der anderen Seite verfolgt MDD nicht das Ziel
sämtlichen Programmcode zu generieren, so dass auch Teile des Programmcodes per Hand geschrieben
werden können und sollen.
Der DDD Ansatz geht auf ein Buch von Eric Evans2 zurück. Folgendes Zitat von der DDD Homepage
beschreibt am besten, was DDD ist: „Domain-driven design not a technology or a methodology. It is a way
of thinking ...“
Die Wurzel allen Übels
2vgl. [Evans04 ]
3MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Im Jahr 1965 hat Gordon E. Moore, Mitbegründer der Firma Intel, das berühmte "Gesetz von Moore"
formuliert, das in Kurzform besagt, dass sich die Anzahl der Transistoren auf einem Prozessor sich alle
12 Monate verdoppelt. Der damit verbundene Leistungszuwachs führt dazu, das sich grob alle fünf Jahre
die Leistungsfähigkeit eines Personalcomputers verzehnfacht.
Da die Anwender dieser immer leistungsfähigeren Hardware bisher immer Wege gefunden haben die
Hardware auszureizen, steht damit das Wachstum der Anforderungen an Software-Projekte in direktem
Zusammenhang. Wer kennt nicht Geschichten von genialen Programmieren, die in den 80er Jahren
alleine ein geniales Programm geschrieben haben und damit reich geworden sind. In den 90er Jahren
bestanden viele Software Projekte schon aus ca. 10 Programmieren und aktuell sind Software-Projekte
mit 100 Entwicklern keine Seltenheit.
Das Gesetz von Moore lässt nun die Vorhersage zu, dass, wenn sich nichts grundlegend ändert, im Jahr
2010 Software-Projekte mit 1000 und mehr Entwicklern zu erwarten sind. Um dieser Entwicklung zu
begegnen müssen die Wege und Verfahren um zu einem lauffähigen Programm kommen in den
nächsten Jahren sich an die neuen Gegebenheiten anpassen.
Abbildung 3. Moore's Law (aus www.wikipedia.org)
Alter Wein in neuen Schläuchen
4MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Nun ist die Idee Programmgeneratoren einzusetzen nicht wirklich neu. In der Vergangenheit haben
verschiedene Firmen immer wieder versucht mit mehr oder wenige guten Generatoren die manuelle
Programmierung weitgehend überflüssig zu machen. Zwar haben einige dabei auch durchaus Erfolge
erzielt, konnten sich auf breiter Front aber kaum durchsetzen. Gescheitert sind diese Ansätze häufig an
mangelnder Performance der erzeugten Programme, an proprietären Beschreibungssprachen oder an
mangelnder Investitionssicherheit, die eine Bindung an ein Werkzeug mit sich bringt, dass nur von
einem Hersteller unterstützt wird.
Ausgangslage
Um die Probleme der Vergangenheit zu umgehen bedarf es einer Beschreibungssprache, die breite
Akzeptanz genießt und von vielen verschiedenen Herstellern mit Werkzeugen unterstützt wird. Insofern
ergibt sich durch den Einsatz der UML als Modellierungssprache eine deutliche Verbesserung
gegenüber den Ansätzen in der Vergangenheit.
Allerdings muss eine Sprache gewisse Voraussetzungen erfüllen, damit sich zur automatischen
maschinellen Weiterverarbeitung eignet. Die Sprache muss wohl definiert sein, d.h. sie muss eindeutig
und widerspruchsfrei sein. Für die UML 1.x galt dieser Anspruch nur teilweise. Mit der UML 2 ist der
OMG hier ein großer Fortschritt gelungen.
Es wachsen aber auch die Anforderungen an die Anwender der UML. Bisher wird die UML in vielen
Projekten eher informell eingesetzt, d.h. die formale Korrektheit der Diagramme ist zweitrangig, solange
die im Entwickler-Team Einigkeit über die Bedeutung der Diagramme herrscht. Die automatische
Verarbeitung der Diagramme fordert aber auch die formal korrekte Anwendung der UML. Die OMG
unterstützt dies durch das UML Zertifizierungsprogramm. Somit soll auch eine formal korrekte
Anwendung der UML gefördert werden.
Das Zertifizierungsprogramm der OMG
Die UML ist mit der Version 2.0 einer kompletten Renovierung durch die OMG unterzogen worden,
kräftig verbessert und in einigen Bereichen erweitert worden. Neben diesen inhaltlichen Neuerungen führt
die OMG mit der Version 2.0 nun auch Qualifikations-Standards in Form eines dreistufigen
Zertifizierungsprogramms ein. Dieses Zertifizierungsprogramm soll sicherstellen, dass UML-Anwender,
Trainer, Berater, Werkzeughersteller u.a. ein einheitliches UML-Verständnis und eine Mindestqualifikation
aufweisen. Die drei Stufen der Zertifikate sind an die Struktur Basic, Intermediate und Complete der UML
2.0 Superstruktur Spezifikation angelehnt.
OMG-Certified UML Professional Fundamental In der ersten Stufe werden fundamentale UML Kenntnisse
geprüft. Hierzu zählen Grundlagen der Klassendiagramme, Aktivitätsdiagramme, Interaktionsdiagramme
und Anwendungsfalldiagramme sowie diverse Elemente wie z.B. Standard-Stereotypen oder Primitive
Typen. Die Grundlagen beinhalten nicht nur die für den UML Anwender sichtbaren Elemente, sondern
auch abstrakte Konzepte der UML wie z.B. Element, die Basisklasse aller UML Klassen im Metamodell.
Diese Stufe ist für den normalen UML Anwender geeignet.
OMG-Certified UML Professional Intermediate In der zweiten Stufe werden die Kenntnisse über
Aktivitätsdiagramme und Interaktionsdiagramme vertieft. Hinzu kommen
Kompositionsstrukturdiagramme, Grundlagen der Komponenten- und Verteilungsdiagramme,
Zustandsdiagramme, das Aktionsmodell und der Erweiterungsmechanismus der Profile. Diese Stufe ist für
den intensiven UML Anwender geeignet.
OMG-Certified UML Professional Advanced In der dritten und höchsten Stufe werden fortgeschrittene
Kenntnisse über Klassendiagramme wie z.B. Assoziationsklassen und Metatypen, über
Kompositionsstrukturdiagramme, Komponentendiagramme, Aktivitätsdiagramme, Aktionsmodellierung,
Verteilungsdiagramme und Protokollautomaten abgefragt. Zusätzlich werden die Themen OCL, UML 2.0
Architektur (u.a. Infrastruktur, MDA), Informationsflussmodellierung, Modelle und Schablonen
(Templates) abgedeckt. Diese Stufe ist für den fortgeschrittenen UML Anwender geeignet (z.B. Designer
ausführbarer Modelle, MDA, Profildesigner, UML Toolentwickler).
5MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Ein weiterer wesentlicher Baustein für den Einsatz eines modell-getriebenen Entwicklungsprozesses ist
das Case-Tool. Die meisten bisher verfügbaren MDA Werkzeuge nutzen das XML Metadata
Interchange (XMI) Format. Hierbei handelt es sich um eine XML basierte Sprache, die den Austausch
von UML Modellen zwischen verschiedenen Werkzeugen gewährleisten soll. Das XMI Format ist
Bestandteil der UML Spezifikation. Im Rahmen der UML 1.x war dieses Austauschformat ebenfalls
beschrieben, aber die Hersteller haben sich nur sehr grob an die Spezifikation gehalten. Somit ist die
Austauschbarkeit von UML 1.x Modellen nur theoretisch gegeben. Dies hat für die derzeit erhältlichen
MDA Werkzeuge die unangenehme Konsequenz, dass meist eine Einschränkung auf ein bestimmtes
UML Werkzeug notwendig ist. Durch die UML 2 hat sich auch hier die Situation wesentlich verbessert,
da die Definition des XMI Formates verbindlicher geworden ist und somit eine höhere Interoperabilität
zwischen verschiedenen Werkzeugen gewährleistet sein sollte. Problematisch sind aber vor Allem
herstellerspezifische Erweiterungen oder Interpretationen des Austauschformats.
Investitionssicherheit
Die Entscheidung ein neues Projekt mit einen modell-getriebenen Entwicklungsprozess umzusetzen fällt
derzeit nicht leicht. Es geht nicht nur darum ein paar neue Werkzeuge einzusetzen, sondern die
Änderung betrifft den ganzen Entwicklungsprozess. Dem Transformationsschritt vom PIM zum PSM
kommt dabei die entscheidende Bedeutung zu. Mit der Qualität der Transformation wird direkt die
Qualität des Endprodukts beeinflusst. Daher wird ein wesentlicher Teil des Programmieraufwands für
die Erstellung und Anpassung des Generators anfallen. Dies kann sich aber nur langfristig bezahlt
machen, wenn mehrere Projekte auf der gleichen Basis abgewickelt werden.
Ebenso müssen die beteiligten Entwickler ihre vorhandenen UML Kenntnisse wesentlich erweitern. Den
die Qualität der UML Modelle ist ein weiterer wichtiger Erfolgsfaktor. Ebenso wie sich in den
vergangenen Jahren die Programmierung immer mehr weg von Assembler Sprachen hin zu
Hochsprachen verlagert hat, wird die Entwicklung immer mehr auf Ebene der UML Modelle stattfinden.
Ein Umstieg auf eine modellgetriebene Entwicklung kann sich nur mittel- bis langfristig bezahlt
machen. Da hierbei, anders als bei früheren Ansätzen, konsequent auf offene Standards gesetzt wird,
sollte die notwendige Investitionssicherheit gegeben sein.
Das Thema Investitionssicherheit lässt sich noch aus einer anderen Sicht betrachten. Die technologische
Basis für Software Projekte ist in den letzten Jahren einem rasanten Wechsel unterzogen. Stichworte
sind CORBA, Java, J2EE, JDO, .NET und viele andere. Es ist sehr schwer zu sagen, welche dieser
Technologien langfristig Bestand haben werden. Und selbst innerhalb einer Technologie können sich
größere Änderungen ergeben. Als Beispiel mag die EJB3 Spezifikation dienen. Nach dem derzeitig
vorliegenden Stand der Spezifikation werden sich gerade im Bereich der EntityBeans sehr große
Änderungen ergeben.
EJB3
Derzeit ist die Version 2.1 der EJB Spezifikation aktuell. Im Hintergrund wird aber bereits die Version 3.0
vorbereitet 3. Diese liegt derzeit als Draft Version vor, so dass man bereits einen Eindruck bekommt, was
die neue Version für Änderungen mit sich bringt.
In der Vergangenheit ist viel Kritik über das nicht gerade einfache Programmiermodell von EJB2 laut
geworden. Dies ist der Grund warum konkurrierende Mechanismen, wie z.B. JDO (Java Data Objects),
eine zunehmende Anzahl von Anhängern finden. Nach der derzeitigen Spezifikation wird sich EJB3 stark
dem Programmiermodell von JDO annähern, tatsächlich werden beide Standards gemeinsam weiter
entwickelt. Damit wird sich aber die EJB Programmierung in Zukunft zwar vereinfachen, aber eben auch
ändern. Die Konsequenzen für aktuelle EJB Entwicklungsprojekte sind daher nicht unerheblich.
3vgl. [Ejb30edr2 ]
6MDA, alter Wein in neuen Schläuchen
oder Weg für die Zukunft?
Grenzen
Mit UML lassen sich hervorragend Strukturen beschreiben (z.B. Klassenmodelle). Durch die
Erweiterungen in der UML2 sind nun auch Aktivitätsdiagramme so ausdrucksstark, dass auch Abläufe
gut modelliert werden können. Aber ein Algorithmus oder eine mathematische Berechnung lassen sich
mit UML kaum angemessen und effektiv darstellen.
Die UML lässt zwar ausdrücklich die Formulierung von Aktionen in bel. Programmiersprachen zu, aber
hier fehlt die Toolunterstützung und ein großer Teil der Platformunabhängigkeit geht verloren, wenn
man z.B. ein C#-Programmfragment im Modell unterbringt. Zwar gibt es als Bestandteil der UML die
Object Contraint Language (OCL), aber letztendlich handelt es sich dabei auch nur um eine weitere
Programmiersprache und bietet damit keinerlei Vorteile gegenüber einer Programmierung in gängigen
Sprachen.
Verfolgt man das Gedankenexperiment weiter in die Zukunft, so wird irgendwann die Programmierung
in den bisher üblichen Programmiersprachen zur Nebensache und nur noch für Spezialanwendungen
sinnvoll (so wie heute in vielen Bereichen die Assemblerprogrammierung). Spätestens dann stellt sich
die Frage nach einem UML Debugger mit Breakpoints und Single-Step Betrieb. Und wie sieht es mit
Unit Tests für UML Diagramme aus?
Sicherlich ist noch einige Arbeit zu leisten und sind noch einige offene Fragen zu klären, bis die
Toollandschaft im Bereich MDA ähnlich vollständig und komfortabel geworden ist, wie wir es derzeit
bei den gängigen Programmiersprachen gewohnt sind. Bis dahin ist an vielen Stellen Handarbeit und
Pragmatismus gefragt.
Ausblick
Was die Zukunft bringt ist nur schwer vorherzusagen. Der Schritt, modellgetrieben Software zu
entwickeln scheint aus der historischen Entwicklung logisch und ist von der OMG auf vielen Feldern
gut vorbereitet. Da sich ein Umstieg auf eine modellgetriebene Entwicklung sicher erst mit der Zeit
bezahlt macht, tun sich viele Firmen verständlicherweise schwer diesen Schritt zu gehen. Die derzeit
verfügbaren Werkzeuge habe noch die eine oder andere Schwäche, und insb. die UML 2 Unterstützung
durch die derzeit am Markt verfügbaren UML Case-Tools ist noch sehr dürftig. Das sollte ich aber im
Laufe der nächsten 12 Monate ändern, so dass MDA tatsächlich der Weg für die Zukunft sein könnte.
Literatur & Links
[Evans04] Eric Evans. Copyright © 2004. Domain-Driven Design. Tackling Complexity in the Heart of Software.
Addison Wesley.
[Ejb30edr2] EJB 3.0 Expert Group. Copyright © 2005. Enterprise JavaBeans(TM) 3.0 Early Draft.
[AndroMDA] Open Source. AndroMDA. http://www.andromda.org/.
[OpenArchitectureWare] Open Source. Open ArchitectureWare. http://architecturware.sourceforge.net/site/.
[MDA04] Object Management Group. Copyright © 2004. MDA Specifications. http://www.omg.org/mda/specs.htm.
7Sie können auch lesen
