Referenzarchitekturen und MDA 1 Gerd Beneken *, Tilman Seifert *, Niko Baehr +, Inge Hanschke +, Olaf Rauch + *) TU München Lehrstuhl für Software & Systems Engineering Boltzmannstr. 3; 85748 Garching +) iteratec Gesellschaft für iterative Softwaretechnologien mbh Inselkammerstraße 4; 82008 München - Unterhaching {gerd.beneken, tilman.seifert}@in.tum.de, {inge.hanschke, niko.baehr, olaf.rauch}@iteratec.de Abstract: Dieser Beitrag beschreibt, wie Referenzarchitekturen die MDA nutzbar machen. Die Referenzarchitekturen liefern dabei die konzeptionelle Unterstützung für die Konstruktion und Implementierung von Software und die MDA bietet den Rahmen für eine Werkzeugunterstützung. Die praktische Umsetzbarkeit wird mit dem OpenSource Framework AndroMDA und einer Referenzarchitektur der Firma iteratec GmbH gezeigt. 1 Risiken der Model Driven Architecture Die Model Driven Architecture (MDA) [MM03] hat große Ziele: Die (UML) Modelle von Softwaresystemen sollen Technologiewechsel überdauern, und die Entwicklungskosten sollen deutlich sinken. Fallstudien versprechen bis zu 35% Kostenersparnis [Mid03]. Ob sich jedoch überhaupt Einsparungen realisieren lassen, hängt von der richtigen Verwendung der MDA ab. Die MDA schlägt mehrere Modelltypen vor: Plattformneutrale Modelle (Platform Independent Model, PIM) werden stufenweise in plattform-abhängige Modelle (Platform Specific Model, PSM) überführt. Schließlich wird aus dem PSM Code erzeugt. Die Überführung der Modelle ineinander und in Code erfolgt manuell oder automatisiert. Die Geschäftslogik lässt sich zur Zeit nicht vollständig in Form von (UML-)Modellen darstellen. Teile der Geschäftslogik und andere spezifische Anforderungen müssen daher in einer Programmiersprache formuliert werden. Damit entsteht eine Mischung aus generiertem Code, welcher auch vom Werkzeughersteller abhängt, und manuell implementierter Geschäftslogik. 1 Diese Arbeit wurde unterstützt vom Bundesministerium für Bildung und Forschung (BMBF) als Teil des Projektes VSEK (Virtuelles Software Engineering Kompetenzzentrum)
Die MDA muss in ihren Aussagen vage bleiben, da sie den Typ der zu erstellenden Softwaresysteme nicht genau festlegt. E-Business-Systeme können ebenso wie Automotive- oder Defence-Systeme erstellt werden. Die Inhalte und der Abstraktionsgrad der Modelle PIM und PSM sind nicht näher spezifiziert. Über die Transformation der Modelle und die Ausgestaltung der Codegenerierung werden derzeit kaum konkrete Aussagen gemacht. Standards sind erst in der Diskussion. Werkzeugherstellern und Nutzern ist diese Gestaltung überlassen. Viele proprietäre Lösungen sind daher am Markt. Referenzarchitekturen helfen bei der Konkretisierung der MDA, da sie viele der notwendigen Festlegungen in Bezug auf die Inhalte der Modelle und die Abbildung auf eine konkrete Plattform durch Code-Generierung treffen. 2 Was sind Referenzarchitekturen? Softwaresysteme, die ähnliche Anforderungen erfüllen, können in gleicher Weise entworfen und implementiert werden. Die Rahmenarchitektur und ihre Elemente (wie Frameworks und Infrastrukturen) können für diese ähnlichen Anforderungen als domänenspezifische Architektur formuliert und damit wiederverwendet werden 2. Abbildung 1: UML-Modell eines Carsharing Systems mit UML-Stereotypen Wiederverwendbare domänenspezifische Architekturen werden im folgenden Referenzarchitekturen genannt. Referenzarchitekturen geben den Rahmen für die Architektur und die Implementierung von Softwaresystemen in einer Domäne vor, dazu definieren sie die grundlegende Strukturierung, wie die Schichtenaufteilung und wichtige Komponententypen. Zentrale Begriffe werden definiert, z.b. Komponente, Schicht oder Schnittstelle. Eine Referenzimplementierung auf mindestens einer technischen Plattform zeigt die Anwendbarkeit der Architektur. 2 Der Begriff Domäne bezeichnet eine Menge gleichartiger Anforderungen und Rahmenbedingungen. E- Business, Automotive oder Finanzdienstleistungen sind Beispiele für technische und fachliche Domänen.
E-Business Systeme haben beispielsweise ähnliche technische Rahmenbedingungen; sie greifen auf Datenbanken zu, arbeiten über Transaktionen und haben eine grafische Oberfläche, die von verteilten Nutzern verwendet wird. Die iteratec E-Business Referenzarchitektur [ite04] gibt dafür eine Rahmenarchitektur und Bauelemente vor. Abbildung 1 ist ein Ausschnitt aus dem UML-Modell für eine Beispielapplikation der Referenzarchitektur (ein Car Sharing System). Das Modell zeigt mehrere Elemente des Anwendungskerns, aus dem Business Service KFZReservieren. Die verwendeten Stereotypen 3 stellen Strukturierungselemente der E-Business Referenzarchitektur dar. 3 Referenzarchitekturen und die MDA Referenzarchitekturen definieren Elemente der Modellierung und damit der PIMs bzw. der PSMs in der MDA. Sie legen die Abstraktionsebene fest, auf der ein System modelliert wird. Je spezifischer die Vorgaben der Referenzarchitektur sind, desto abstrakter kann modelliert werden; im Gegenzug ist ihre Einsatzbandbreite geringer. Die Modellelemente können als Stereotype für UML-Werkzeuge verfügbar gemacht werden. Modelle für verschiedene Systeme der gleichen Domäne werden damit vereinheitlicht. Zusätzlich werden Begriffe wie Business Service definiert, welche die Sprache der Entwickler und Architekten vereinheitlichen. Die Modelle sind Grundlage für die Codegenerierung. Die Stereotype reichern diese mit implementierungsrelevanten Informationen an. Aus einer Business Service Facade kann beispielsweise ein Stateless SessionBean für J2EE Applikationen generiert werden. 4 Praktische Umsetzung mit AndroMDA Das OpenSource Framework AndroMDA [And04] versteht sich als MDA-konformes Framework, das Code aus UML-Modellen generieren kann. AndroMDA liest UML- Modelle im XMI1.1 oder XMI1.2 4 Format ein. Dieses kann von gängigen UML- Werkzeugen erzeugt werden. Jedem Stereotyp in dem UML-Modell können ein oder mehrere Generierungstemplates zugeordnet werden, z.b. ein Template zur Generierung einer Business Activity Java Klasse aus einem Business-Activity-Modellelement. Ein Template ist in der Regel Code, der in einer Skriptsprache (Velocity) flexibilisiert ist, beispielsweise werden Klassennamen und Attributnamen ersetzt durch Generierungsvariablen. AndroMDA setzt beispielsweise Namen aus dem UML-Modell in die Templates ein und generiert damit Code. Abbildung 2 zeigt den prinzipiellen Ablauf der Generierung. 3 Stereotype sind erlaubte Erweiterungen der UML-Notation, innerhalb des UML-Metamodells 4 XMI ist ein XML basierter, von der OMG definierter, Standard, um UML-Modelle zwischen verschiedenen Modellierungswerkzeugen austauschen zu können.
Abbildung 2: Generierung mit AndroMDA [And04] AndroMDA verfolgt das Konzept, manuelle Ergänzungen nicht direkt im Generat vorzunehmen. Stattdessen soll von jeder generierten Klasse eine Klasse mit manuellem Code abgeleitet werden (dafür wird einmalig eine Vorlage generiert), um den manuellen Code zu isolieren und zu schützen. Bei der Firma iteratec GmbH wurde eine erste MDA-Unterstützung für die E-Business Referenzarchitektur über AndroMDA entwickelt: Die Elemente der Referenzarchitektur wurden in ein Modellierungswerkzeug in Form von UML-Stereotypen übernommen (vgl. Abbildung 1). Aus der konsolidierten Beispielanwendung der Referenzarchitektur wurden die Generierungstemplates der UML-Stereotype für AndroMDA entwickelt. Die UML-Modelle für die Beispielanwendung wurden mit den UML- Stereotypen ergänzt. Diese sind das PSM der Beispielanwendung im Sinne der MDA, da die dargestellten Architekturelemente bereits auf die technische Plattform J2EE ausgerichtet sind, wenngleich noch nicht von Enterprise JavaBeans die Rede ist. Aus dem PSM wurde mit AndroMDA und den erstellten Templates Code für die Beispielapplikation generiert und die nicht generierbaren Teile der Geschäftslogik wurden ergänzt. Die generierte und die manuell implementierte Beispielapplikation wurden zur Qualitätssicherung gegeneinander abgeglichen. Ergebnis ist damit ein erster funktionierender Prototyp für die Instrumentierung der MDA und eines Werkzeugs mit einer E-Business Referenzarchitektur. Die Erfahrungen mit Modellierung und Codegenerierung sind bislang positiv. Die Modellierung wird durch die aussagekräftigen Stereotype deutlich erleichtert. Ein großer Teil des fehlerträchtigen, gleichartigen Codes kann generiert werden, spart damit Entwicklungsaufwände und verbessert die Gesamtqualität.
Dynamische Anteile der Geschäftslogik können derzeit nicht vollständig über Modelle dargestellt werden und sind daher manuell zu implementieren. Das Konzept, manuellen Code in abgeleiteten Klassen zu sammeln, erwies sich als sinnvoll. Probleme bei Neugenerierungen waren selten. Änderungen in der konkreten Ausgestaltung der Abbildung auf die J2EE-Plattform waren ohne große Anpassungen an manuellem Code möglich. AndroMDA wird in diesem Ansatz als Codegenerator verwendet. Auf Modell-Modell- Transformationen, wie es die MDA vorsieht, wird noch verzichtet. Die Automatisierbarkeit des Entwicklungsprozesses mit der MDA und die dafür erforderlichen Modell- Modell-Transformationen werden noch geprüft. 5 Zusammenfassung Die Model Driven Architecture enthält interessante Konzepte. Eine breite Werkzeugunterstützung ist in diesem Bereich zu erwarten, insbesondere bei Modelltransformationen und der Codegenerierung. Die MDA trifft leider wenige Festlegungen in Bezug auf konkrete Ausgestaltung der Modelle, Modelltransformation, Abstraktionsgrad der Modelle und Codegenerierung. Nutzer und Werkzeughersteller müssen diese Lücken füllen. Referenzarchitekturen definieren einen Rahmen für die Architekturen von Softwaresystemen in einer bestimmten Domäne. Sie legen Architekturelemente und damit Modellelemente sowie Abbildungen auf technische Plattformen und auf Code fest. Sie definieren zusätzlich den Abstraktionsgrad in dem Systeme modelliert werden. Referenzarchitekturen liefern die domänenspezifische Konkretisierung, welche der MDA fehlt. Dieser Beitrag zeigt einen ersten Schritt, die Softwareentwicklung durch die Kombination einer Referenzarchitektur mit dem MDA-Ansatz zu unterstützen. Ergebnisse sind eine verbesserte Modellierung über aussagekräftige UML-Stereotype und ein MDAkonformer Codegenerator, der UML-Modelle auswertet und Rahmenklassen für E-Business Systeme generiert. Modell-Modell Transformationen (und damit die weitere Automatisierung des Entwurfsprozesses) werden noch nicht betrachtet. Hier sind zunächst die methodischen Grundlagen (ein Entwicklungsweg von Anforderungen zum Code) zu konsolidieren. 6 Literaturverzeichnis [And04] AndroMDA-Webseite, April 2004, (http://www.andromda.org) [ite04] iteratec: E-Business Referenzarchitektur J2EE Edition, Management Zusammenfassung; iteratec GmbH; 2004, (http://www.iteratec.de) [Mid03] The Middleware Company: Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach Productivity Analysis, June 2003 [MM03] Miller, J., Mukerji, J.: MDA Guide 1.0, omg/03-05-01, Mai 2003 (http://www.omg.org/)