DOAG News Q3-2008 | 23

Entwicklung

Da die meisten Architekturen und Verantwortlichen meist nur in Schrift-form festgehalten sind, lassen die Ar-chitektur-Beschreibungen einen gro-ßen Raum für Interpretationen und werden somit von den Beteiligten sehr unterschiedlich ausgelegt. Das Resultat ist dabei meist, dass in einem Unter-nehmen viele Software-Architektur-Facetten mit unterschiedlicher Qua-lität entstehen, die sich trotz Einsatz leistungsfähiger Frameworks wie ADF, Spring oder Toplink kaum noch mana-gen lassen. Dieser Umstand hat unter anderem Oracle Consulting angeregt, zusammen mit Oracle Forms-Kunden eine modellgetriebene Entwicklungs-methode zu implementieren, die eine komplette Architektur (SOA, ADF, JEE, POJO, ...) automatisch instanziiert. So-mit kann der Großteil der Entwickler sich auf die Fachlichkeit konzentrie-ren.

Dieser Artikel zeigt in einem Oracle-spezifi schen Projektkontext, weshalb und wie Model Driven Software De-velopment (MDA/MDSD) eingesetzt wird. Es wird davon ausgegangen, dass die Grundkonzepte von MDA/MDSD bereits bekannt sind.

Status Quo in typischen IT-Landschaften

Beim Betrachten des kompletten Le-benszyklus einer IT-Anwendung erge-ben sich typische Herausforderungen. In der Planungsphase müssen die fach-lichen und technischen Grundlagen des Projekts defi niert sein. Charakteris-tische Entscheidungen, die im Rahmen einer technischen Planung getroffen werden, sind unter anderem:

Aufbau der Architektur (Schichten-•

modell, Serviceorientierung etc.)

Model Driven Software Development und Oracle – eine gute Mischung

Autoren: Berthold Maier und Claus Straube, ORACLE Deutschland GmbH

Architektur-Management ist in den letzten Jahren mehr und mehr in Entwicklungsprojekten in den Vordergrund getreten. Bedingt durch die Anforderungen schaffen Architekten schaffen oft komplexe Architekturen und verwenden dabei viele Frameworks (Java EE, ADF, Spring, .NET etc.), die von Entwicklern beherrscht werden müssen.

Implementierungssprache (Java, PHP •

etc.)Frameworks (ADF, Spring, JEE etc.)•

Diese Entscheidungen prägen den Ver-lauf eines Projekts und die Zukunft einer Anwendung fundamental. Fehlt eine einheitliche IT-Architektur-Strate-gie, so werden diese Entscheidungen bei jedem IT-Projekt neu getroffen. Dies kostet vor, während und vor allem nach der Implementierung (Betrieb) Zeit und somit Geld. Anwendungs-design und Technologie-Entschei-dungen werden in der Praxis oftmals nicht nach objektiven Kriterien gefällt (organisationsweite einheitliche Archi-tektur), sondern sind sehr stark von den Vorlieben und dem Know-how des Entwicklungsteams geprägt. Vie-le Anwendungen laufen deshalb Ge-fahr, dass eine Architektur auf einem Technologie-Hype oder den Vorlieben und Kenntnissen einzelner Entwickler ausgerichtet und nicht immer auf die tatsächlichen Bedürfnisse der Organi-sation zugeschnitten wird.

Ergebnis einer solchen „IT-Strategie“ ist eine Anwendungslandschaft in der zahlreiche Technologien und Frame-works, wie PHP, Java, Visual Basic, APEX, Forms, ADF, SOA, BPEL, Struts, Spring, Hibernate, Toplink, JDBC, JSP, HTML oder XSLT vertreten sind. So zahlreich wie die eingesetzten Frame-works und Technologien, so zahlreich müssen die entsprechenden Skills zur Implementierung und vor allem zur Wartung der Applikationen vorhan-den sein. Da in der Regel die Anzahl der Mitarbeiter begrenzt ist, müssen mehrere Personen viele Technologie-Bereiche parallel beherrschen. Dadurch entstehen unserer Erfahrung nach fol-gende Probleme:

Die Entwickler sind oft überfordert,•

da die Technologien zumeist sehr komplex sind und sich zudem schnell weiter entwickeln. So ent-steht Frustration. Die Beteiligten trauen sich nicht, den Code des Kol-legen, der beispielsweise gerade aus dem Unternehmen ausgeschieden ist, anzufassen – auch wenn es drin-gend notwendig sein sollteDie Entwickler müssen ständig mit •

wechselnden Technologien oder Frameworks arbeiten. Dadurch kön-nen sie sich in diesen oft nur ober-fl ächliche Kenntnisse aneignen. Den Aufbau eines Spezialistenteams und die Konzentration auf Fokus-Techno-logien ist somit sehr schwer möglich. Unter dieser fehlenden Fokussierung leiden unter anderem Code-Qualität und EntwicklungsgeschwindigkeitIst die Entwicklungsproduktivität •

niedrig, bleibt nur wenig Zeit für Tä-tigkeiten, die zusätzlich zur eigentli-chen Programmierung anfallen. Die-ser Zeitnot fällt zum Beispiel oft die Erstellung einer Dokumentation, die wirklich den aktuellen Stand der An-wendung widerspiegelt, zum Opfer. In einer stark fragmentierten IT-•

Landschaft ist es aus Erfahrung al-lein durch formale Beschreibungen und ohne zentrale MDSD-Strategie schwer möglich, organisationswei-te Architektur- und Implementie-rungsmuster durchzusetzen. Ohne diese generierbaren Vorgaben im-plementieren die Entwickler in einer solchen ungemanagten Umgebung oft unterschiedliche Lösungsmuster für identische Problemstellungen, die – abhängig vom Entwickler-Skill – mehr oder weniger gut auf die Anwendungslandschaft ausgerich-tet sind. Das macht die Wartbar-

24 | www.doag.org

Entwicklung

keit und Ausbau einer IT-Landschaft sehr schwer und die Betriebskosten steigen in die Höhe

Ein klassisch implementiertes System führt in der Regel dazu, dass eine ein-mal laufende Anwendung hinterher nur noch mit hohem Aufwand ver-ändert werden kann, beziehungsweise im schlimmsten Fall von den Entwick-lern nicht mehr angefasst werden will. Technologie- oder Release-Updates zö-gern sich damit hinaus und die Lauf-zeit der Anwendung bis zur erstenReimplementierung verkürzt sich er-heblich. Der Investitionsschutz ist da-mit kaum gegeben.

Wie kann MDSD helfen?

Model Driven Software Development (MDSD) bietet unabhängig von der gewählten Technologie – einschließ-lich PL/SQL, DDL, PHP, Java etc. – für die oben genannten Problemfelder Lösungsansätze. MDSD ist erfahrungs-gemäß für alle Skill-Level anwendbar und ermöglicht somit auf einfache Weise einen Einstieg in ein zielgerich-tetes Software Engineering.

MDSD ist eine technologieunab-hängige Software-Engineering-Metho-dik, mit der es möglich wird, eine Architektur und den dazugehörigen Technologie-Stack ohne Reimplemen-tierung immer wieder zu erneuern und in den jeweiligen spezifi schen fachlichen Kontext zu reproduzieren. Anwendungen, die auf Basis desselben MDSD-Metamodells aufgebaut werden, sind von der Architektur und der Tech-nologie nahezu identisch und damit in der Regel gut beherrschbar. Mitarbeiter können somit mehrere Projekte gleich-zeitig begleiten und ihr spezialisiertes Know-how besser streuen. Damit sinkt die Gefahr, dass die mit MDSD erstell-ten Anwendungen schnell unwartbar werden – man denke nur an den Aus-stieg eines Haupt-Entwicklers.

Diese Vorteile erreicht MDSD nur durch einen Abstrahierungsgrad der eingesetzten Technologien. Der Fach-entwickler muss bei MDSD nicht alle Details eines Frameworks wie ADF, Spring oder Toplink verstehen, son-dern nur noch wissen, was er model-

lieren und welche generierten Artefak-te er modifi zieren muss. Technikaffi ne Entwickler werden jedoch durch den steuerbaren MDSD-Generator befä-higt, jedes Bit des Generats auf einfa-che Weise zu beeinfl ussen, womit das Gefühl des Black-Box-Ansatzes genom-men wird. Diese Entwickler und Archi-tekten gießen sozusagen ihre Referenz-Architektur und Umsetzungsbeispiele in Generator-Templates (Code-Vorla-gen für den Generator) und stellen sie dem gesamten Entwicklerteam bereit.

Beispielsweise muss in einem MDSD-Projekt der Fachentwickler nur noch wissen, dass eine Objekt-Instanz mit getBean(„Name“) geholt wird – um Web-Service-Aufrufe, Spring- be-ziehungsweise Toplink-Konfi guration und Patterns wie DAO, Fascade oder Service-Locator braucht er sich gar nicht mehr zu kümmern. Dadurch ist es möglich, auch nicht so geübte Entwickler produktiv im komplexen Architektur-Umfeld einzusetzen.

Ein weiteres Argument für MDSD ist die höhere Software-Qualität. Sie wird durch ein standardisiertes Ent-wicklungsvorgehen und die zugrun-de liegende Referenz-Architektur ge-steigert. In MDSD-Projekten werden plattformabhängig alle Best Practices im Generator hinterlegt. So ist es mög-lich, aus unterschiedlichen Modellen immer wieder Software mit identi-scher Qualität zu generieren. Zudem werden zu jedem Artefakt (Java, JEE, SOA, PL/SQL) entsprechende Tests generiert. Werden dennoch Fehler im Infrastruktur-Code der Anwendungs-software gefunden, so können diese in den Generator-Templates ausgebessert werden – und sind nach dem nächsten Generierungsvorgang in der gesam-ten Applikation eliminiert. Das häu-fi g sehr aufwendige Code-Refactoring und Fehlerbeheben lassen sich damit einfach realisieren. Effi zientes Debug-ging und die Lesbarkeit des Codes darf in diesem Zusammenhang nicht unterschätzt werden. Mit dem Gene-rator wird kein „Magic-Code“ erstellt, sondern ein lesbarer und debugfähi-ger Code, der sich genauso verhält, als wäre das Programm zu 100 Prozent von Hand geschrieben. Da der Gene-rator ausschließlich zur Generierungs-

zeit zum Einsatz kommt, sind keine speziellen Runtime-Bibliotheken not-wendig. Die Wartung vorhandener Ap-plikationen ist eine weitere Stärke von MDSD. Viele Anwendungen werden heute nach dem Prinzip „never touch a running system“ ungern großen Ver-änderungen ausgesetzt. Gründe dafür sind oft, dass sich Mitarbeiter im Code nicht mehr zurechtfi nden oder bereits geringe Änderungen das System in einen instabilen Zustand versetzen. Die Erfahrung hat gezeigt, dass sich bei Verwendung von Model Driven Software Development der Aufwand bei Änderungen etwa um den Gene-rierungsfaktor verringert. Das kann abhängig der gewählten Architektur den Aufwand um rund 50 Prozent reduzieren. Datenbank-Anpassungen ziehen in einem aktuellen Projekt etwa eine Stunde Aufwand durch alle Schichten nach sich. Der durch-schnittliche Aufwand ohne MDSD beträgt in dem komplexen System in der Regel mehr als einen Tag. Techno-logie-Wechsel wie das Ersetzen von Toplink „Klassik“ durch JPA zieht nur minimale Anpassungen innerhalb der Applikation nach sich und ist durch die 100-prozentige Generierung dieser Schicht in wenigen Tagen inklusive Tests vollzogen.

Abbildung 1: Was wird generiert?

Eine seiner größten Stärken hat MDSD in dem Bereich, in dem man sie auf den ersten Blick gar nicht vermutet: in der Dokumentation. Das Modell an sich – in diesem Fall ein mit UML-Profi l angepasstes und vereinfachtes UML2-Modell, das leicht verständlich ist – hat schon Dokumentations-Charakter. Anstatt zusätzlich zum Programmieren zu dokumentieren, steht das Modell im Zentrum und liefert einen Mehrwert für alle. Es wird praktisch im Rahmen

DOAG News Q3-2008 | 25

Entwicklung

«DEFINE ddlScript FOR BusinessModel»«File Name+”.sql”-» . . .«FOREACH entities AS entity -» DROP TABLE «entity.Name»;«ENDFOREACH»

«FOREACH entities AS entity-» CREATE TABLE «entity.Name»; «FOREACH entity.attributes AS attribute SEPARATORʻ,ʼ-» «attribute.Name» «attr.SQLType» «IF attr.Range.matches(“”) == false» («attribute.Range») «ENDIF» ...«ENDFOREACH»

Listing 1: Code-Template zur Datenbank-Generierung

der Entwicklungstätigkeit das Modell dokumentiert. Somit ist die Dokumen-tation immer auf dem aktuellen Stand, da ja aus dem Modell der Code und die Dokumentation (= Modell) abgeleitet werden und nicht umgekehrt.

MDSD-Realisierung

Am Anfang einer MDSD-Architektur steht immer eine Referenz-Architektur. Diese stellt zu einer Problemstellung eine erprobte Lösungs-Architektur dar – sie sollte mindestens ein- oder mehrfach erfolgreich im Betrieb sein. In der Regel existieren pro Referenz-Architektur eine oder mehrere Tech-nologie-Bindungen. Bei einer auf dem Oracle Technologie-Stack basierenden MDSD-Referenz-Architektur sind dies: Oracle ADF 11g, /10g, Spring-Frame-work und Java EE sowie Fusion SOA. Abhängig den Anforderungen und Kundenwünschen können im Projekt die verwendeten Technologien einfach ausgetauscht, modifi ziert oder um eine neue erweitert werden. Realisiert wird die Technologie-Bindung durch Ein-bettung des Codes in die Generator-Templates (siehe Listing 1).

Die Templates interpretieren wäh-rend des Generierungsvorgangs die von den Fach- oder Entwicklungs-Designern nach den festgelegten Bestimmungen erstellten Modelle und generieren aus diesen den entsprechenden technolo-gieabhängigen Code.

Die Modellierungskonventionen sind in MDSD technologieneutral im Meta-Modell festgeschrieben. Dieses beschreibt unter anderem, welche Elemente einer Modellierungssprache – in diesem Fall UML – wie verwen-det werden sollen. Zum Erstellen ei-nes solchen Meta-Modells bieten die gängigen Werkzeuge einen grafi schen Editor. Das Meta-Modell muss sowohl im Modellierungswerkzeug als auch im Generator semantisch identisch sein, um während des Generierungsvorgan-ges eine korrekte Interpretation des Modells zu gewährleisten.

Im Modell werden die Diagramme auf Basis des Meta-Modells modelliert. Um zum Beispiel ein Daten-Objekt mit Attributen zu modellieren eignen sich in UML speziell gekennzeichnete Klas-sen (beispielsweise mit dem Stereotyp „Entity“). Diese „Entity“-Klassen wer-den zur Generierung vom dem ent-sprechenden technologiegebundenen Template zum Beispiel als Datenbank-Tabelle und die Attribute als Spalten interpretiert. Das Modell könnte um zusätzliche Attribute der Modellie-rungssprache (Tagged-Values) angerei-chert werden, um in technischen Mo-dellen Storages-Clauses abzulegen.

Das Modell sollte in einem grafi -schen Modellierungswerkzeug erstellt werden. Gut geeignete Tools sind zum Beispiel MID-Innovator, MagicDraw, Enterprisearchitekt, ARIS, Poseidon und Apollo. Als Modell können je-

doch auch andere Quellen verwendet werden. Beispielsweise sind auch Text-Dateien oder gar die Datenbank als Informationslieferant geeignete Orte, um ausgewählte Teile einer Software zu beschreiben und daraus Code oder Konfi gurationen zu generieren.

MDSD im Projekteinsatz

Zum Schnelleinstieg wird für MDSD-Projekte eine Starter-Applikation auf Basis von Apache Maven, Open Ar-chitecture Ware, MID Innovator und der Oracle Technologie-Bindung er-stellt. Per Maven-Script werden die Projekt-Struktur, das Generator-Setup (inklusive Meta-Modell, Templates und Cartridge zum Modellierungs-werkzeug), Meta-Modell, Beispiel-Mo-dell und die MDSD-Dokumentation erstellt. Die Dokumentation beschreibt Schritt für Schritt, wie die Infrastruktur aufgebaut wird. Dies beinhaltet unter anderem die Einbindung des mitgelie-ferten Repositories (Metamodell + Bei-spielmodell) in Innovator. Das Paket wird zum initialen Projekt-Setup ver-wendet. Somit reduziert sich der Auf-wand beim Start eines neuen Projekts fundamental – und die Projekt-Struk-tur samt Dokumentation ist metho-denkonform angelegt. Durch diesen Ansatz ist MDSD in jedem Projekt, unabhängig von seiner Größe und verwendeten Technologie schnell und effektiv einsetzbar. Der MDSD-Einsatz lohnt sich somit auch für kleine Pro-jekte oder auch in Projekten, in denen etwa nur die Datenbank (SQL) und kein Java oder JEE generiert werden sollen (siehe Abbildung 2).

Nur einfach gestaltete Entwicklungs-ansätze werden von den Entwicklern auch angenommen. Eine große Heraus-forderung ist es deshalb, den Entwick-lungszyklus mit MDSD sehr einfach zu gestalten. Die Entscheidung, auch den Build- und Generierungs-Prozess auf dem Open Source Buildtool Maven aufzubauen, ist Erfahrungen nach für den Erfolg eines modellgetriebenen Vorgehens von großer Bedeutung. Das heißt, dass durch ein eigenes Maven-Kommando (mvn install) der Gene-rierungs-Workfl ow gestartet wird, die Anwendungs-Komponenten erstellt,

26 | www.doag.org

Entwicklung

Abbildung 2: Die MDSD-Infrastruktur

Abbildung 3: Vergleich der Aufwände

kompiliert, automatisch getestet und, wenn gewünscht, auch gleich deploy-ed werden.

Um weitestgehend eine Integra-tion in die Entwicklungsumgebung zu erreichen, kann mit dem Kommando mvn jdev:jdev ein entsprechend kon-fi guriertes JDeveloper-Projekt über Ma-ven erzeugt werden.

MDSD und SOA

BPEL, WSDL, ESB, WISIF, WS-Proxy etc. sind einige Schlagworte, die ein Ent-wickler in SOA-Umfeld beherrschen muss. Darüber hinaus sind auch im SOA-Umfeld Architektur-Muster wieService-Common-Data-Format, Service-Kategorisierung, Cross-Reference und mit einem höheren SOA-Reifegrad vor allem Governance mit all seinen Facet-ten wichtige Themen die gemanaged werden müssen. Die Entscheidung SOA und MDSD zu verbinden, hat sich als wahrer Erfolg herausgestellt. Mit MDSD werden in der Regel technische Artefakte wie WSDL-Dateien, MTOM-Attachments etc. für markierte Services automatisch generiert.

Zudem wird ein konsistentes Com-mon-Data-Format als XSD-Schema-Bibliothek automatisch erstellt und von allen generierten Services refe-renziert. Dieser Ansatz verhindert unter anderem, dass BPEL zum XML-Mapping-Tool wird und die Prozess-Orchestrierung in den Hintergrund tritt. Hinweis: Es gibt viele Projekte, bei denen mehr als 90 Prozent des BPEL-Codes aus XSD-Transformationen so-wie Variablen-Mapping besteht und damit eine unfl exible SOA entsteht.

Governance, sprich das Verwalten der Services inklusive Beschreibungen, Abhängigkeits- und SLA-Management, lässt sich durch sukzessive Erweiterung der MDSD in dem zentralen Modell-Repository ideal verwalten. Service, Policies, UDDI-Export, Software-Land-karten und auch Reports werden unter anderem daraus generiert und stellen über die erweiterten Governance-Mo-delle Abhängigkeitsbeziehungen in ei-ner immer konsistente Form dar.

Abgrenzung zu Case-Tools und Werkzeugen

Auf den ersten Blick scheint MDSD den gleichen Ansatz der altbekannten Case-Werkzeuge wie Oracle Designer oder JHeadstart oder Wizzard-Frame-works zu implementieren. Der großeUnterschied besteht jedoch in der Anpassbarkeit sowie der Abstraktion von Code und Model. Case-Tools wie Oracle Designer geben die Plattform

beziehungsweise Technologie-Bindung relativ fest vor. Diese können meist nur durch Konfi gurationsparameter in ih-rem Rahmen angepasst werden. Einen Plattform- oder Technologie-Wechsel kann weder durch den Endanwender noch den Hersteller einfach vollzo-gen werden. Im Gegensatz dazu ist das Meta-Modell in MDSD technologiefrei und kann so projektübergreifend ein-gesetzt werden.

Fazit

Viele Projekte, in denen MDSD als Entwicklungsmethode gewählt wurde, sind nicht zuletzt durch die gewonnene Flexibilität und Entwicklungsgeschwin-digkeit sehr erfolgreich, sondern auch durch die Fähigkeit, neue Themen und Technologien schneller adaptieren zu können. Jedoch hat die Erfahrung ge-zeigt, dass durch den erhöhten initialen Einführungsaufwand viele IT-Verant-wortliche den MDSD-Einsatz scheuen und sich dagegen entscheiden.

Als Hilfestellung und zur Senkung der initialen Einstiegsbarriere hat OracleConsulting sich entschlossen, die auf dem Oracle Fusion-ADF-11g-Stack ba-sierenden MDSD-Technologie-Temp-lates mit dem OpenSource Generator oAW und die initiale Starter-Anwen-dung in Oracle-Projekten frei zur Ver-fügung zu stellen.

Kontakte:Berthold Maier

berthold.maier@oracle.comClaus Straube

claus.straube@oracle.com

Termine der Swiss Oracle User Group die Sie nicht verpassen

sollten!

31. August 2008

Redaktionsschluss

SOUG Newsletter 2008/4

11. September 2008 Baden-Dättwil

DBA SIG

Oracle Fusion Middleware, Security, …

15. November 2008

Redaktionsschluss

SOUG Newsletter 2009/1

18. November 2008 Baden-Dättwil

DBA SIG

IT Experience & Best Practices

27. November Genf

DEV SIG Suisse Romande

Oracle Haute Disponibilité (Dataguard ou Standby Database)

Weitere Informationen und Anmeldung unter www.soug.ch event@soug.ch Tel. +41 61 367 93 30