MDA, alter Wein in neuen Schläuchen oder Weg für die Zukunft?

Transkript

1 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 ] 1

2 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 2

3 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 ] 3

4 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 Alter Wein in neuen Schläuchen 4

5 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). 5

6 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 EJB3 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. 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 ] 6

7 Grenzen Ausblick 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. 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 Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison Wesley. [Ejb30edr2] EJB 3.0 Expert Group. Copyright Enterprise JavaBeans(TM) 3.0 Early Draft. [AndroMDA] Open Source. AndroMDA. [OpenArchitectureWare] Open Source. Open ArchitectureWare. [MDA04] Object Management Group. Copyright MDA Specifications. 7