Vom Geschäftsmodell zum Code – Komponentenbasierte Entwicklung auf Basis der Model Driven Architecture U. Sommer, G. Rackl, K. Beschorner, H. Kößler, A. Bien Zentrale IT, Kompetenzzentrum IT-Architekturen BMW Group 80788 München {ulrike.sommer, guenther.rackl, klaus.beschorner, heinz.koessler}@bmw.de [email protected]

Abstract: Die Model Driven Architecture (MDA) führt das Konzept universell gültiger Anwendungsmodelle in die Softwarelandschaft ein und ermöglicht die effiziente Abbildung von Geschäftsprozessen auf Code. Dieser Artikel zeigt einen durchgängigen Entwicklungsweg vom Geschäftsmodell zum Code anhand der in der BMW Group auf Basis der MDA entwickelten Component Architecture (CA).

1 Überblick und Zielsetzungen Aufgrund der steigenden Komplexität und der wachsenden Verbreitung von Technologien wie J2EE, CORBA oder .NET setzen sich modellgetriebene Entwicklungsmethoden zunehmend in der Praxis durch. Dabei wird in der fachlichen Modellierung zunächst auf die direkte Verwendung konkreter Technologien verzichtet, da dies zu einer Hersteller- bzw. Technologieabhängigkeit führt. Die Transformation fachlicher Modelle in eine konkrete Technologie erzielt weitere Vorteile, da technologiespezifisches Expertenwissen in Form von Entwurfsmustern und Best Practices mit einfließen kann. Vor diesem Hintergrund wurde in der BMW Group eine Komponentenarchitektur für die durchgängige Abbildung von Geschäftslogik auf eine unternehmensweite ITAnwendungsarchitektur entwickelt. Der modellgetriebene Ansatz der Component Architecture (CA) basiert auf dem generativen Entwicklungsweg der Model Driven Architecture (MDA) und den damit verbundenen drei Architekturschichten: Platform Independent Model (PIM), Platform Specific Model (PSM) und Implementierung. Die Komponentenarchitektur besteht aus den folgenden Elementen: •

Ein Modellierungsprofil, mit dessen Hilfe das plattformunabhängige Modell auf Basis der UML und allgemeinen Architekturprinzipien formuliert werden kann.

•

Modell-Transformatoren, die das Modellierungsprofil auf das J2EE 1.3 konforme plattformspezifische Modell und anschließend auf Code abbilden.

•

Ein Framework, das redundanten J2EE-Code kapselt und dem Anwender als Basisfunktionalität zur Verfügung stellt.

106

In allen drei Elementen werden gängige Entwurfsmuster, Best Practices und konzernweit gültige Richtlinien bei der Implementierung von Softwaresystemen berücksichtigt. Da die modellbasierte Architektur Geschäftslogik und Technologie trennt, können die UML-Modelle bei einem Technologiewechsel im vollen Umfang wiederverwendet werden. Insgesamt verspricht die Verwendung einer homogenen Applikationsarchitektur eine wesentliche Verfeinfachung der Qualitätssicherung, Betreibbarkeit und Pflege von Anwendungen.

2 Die Komponentenarchitektur In der CA wird die Geschäftslogik zunächst technologieneutral in einem Komponentenmodell (PIM) mit Hilfe der UML spezifiziert. Dieses generische Modell wird ausgehend von vorhandenen Anforderungen und Analyse-Modellen erstellt und anschließend unter Rückgriff auf plattformspezifische Transformationsregeln mit einem Modell-Transformator auf die J2EE 1.3 Plattform abgebildet (PSM). 2.1 Die CA-Komponentenwelt Den Kern der CA-Designsprache bilden die Geschäftsobjekte, die als granulare und hoch wiederverwendbare Einheiten Daten, Logik und Regeln zusammenfassen und in Komponenten strukturiert sind. Die CA versteht unter dem Begriff „Komponente“ eine konsistente, eigenständige Einheit, auf die nur über ihre fachliche Schnittstelle zugegriffen wird. Alle verfügbaren Modellierungselemente (Artefakte) der CA sind in Abbildung 1 dargestellt. Die Artefakte lassen sich gemäß ihrer Aufgaben in „ServiceSchnittstellen“, „Ablaufsteuerung“, „Verhalten“ und „Daten“ strukturieren.

Abbildung 1: Aufbau einer Komponente

107

Die wichtigsten Modellierungselemente der CA sind: •

Business Component (BC): Bildet einen Container, der verschiedene CAArtefakte auf Basis bestimmter Architekturvorschriften gruppiert. Wichtig ist die Unterscheidung zwischen der Außensicht (Spezifikation) und der Innensicht (Realisierung) einer Komponente.

•

Business Component Interface (BCI): Bildet die Service-Schnittstelle, die von den Clients bzw. der Präsentationslogik verwendet wird. Das BCI ist Bestandteil der Spezifikation und gewährleistet somit auch die einfache Wiederverwendbarkeit und Testbarkeit der Komponenten.

•

Business Facade (BF): Regelt die Ablaufsteuerung der modellierten Use Cases und übernimmt die Abbildung von fachlichen Prozessen. Zu ihren Aufgaben gehört beispielsweise die Verwaltung von Fehlermeldungen, die Transaktionssteuerung und die Realisierung der Sicherheit.

•

Business Activities (BA): Repräsentieren das fachliche Verhalten, wie z.B. notwendige Algorithmen. Eine BA ist transient und zustandslos. Jede einzelne Methode einer BA bildet eine atomare Aktivität ab.

•

Business Entities (BE): Sind für die eigentliche Datenhaltung zuständig. Eine BE besteht aus einer zusammengehörigen Gruppierung von Attributen mit fachlichen oder elementaren Datentypen.

2.2 Die Abbildung auf J2EE 1.3 Die Formalisierung der zu verwendenden Modellierungselemente und deren durchgängige Verwendung im PIM ermöglicht die automatisierte Abbildung auf die J2EE-Plattform. Die Architektur des J2EE-PSM basiert im Wesentlichen auf den bekannten J2EE-Patterns [ACM01]. Eine technologiefreie PIM-Komponente wird dabei auf mehrere technische Komponenten (z.B. EJBs) abgebildet (siehe Abbildung 2). Eine Business Entity wird beispielsweise abhängig von einem Eigenschaftswert auf ein Data Access Object Pattern (DAO) abgebildet oder durch eine CMP (Container Managed Persistence) Entity Bean modelliert. Der Zugriff auf eine BE erfolgt durch die BA, abgebildet als Stateless Session Bean (SLSB) mit Local Interfaces. Für den Zugriff wird stets ein BEFacadeInterface verwendet. Mit diesem Ansatz können jederzeit bestehende Entity Beans mit DAO-Implementierungen ausgetauscht werden, ohne die SLSB anpassen zu müssen.

3 Generative Entwicklung auf Basis der Model Driven Architecture Die Entwicklung mit der CA basiert wie beschrieben auf dem Ansatz der Model Driven Architecture [MM03]. Neben der Definition der Modellebenen PIM, PSM, und

108

Abbildung 2: Abbildung einer Business Entity auf die J2EE-Plattform

Implementierung (Source Code) spielt hier die Automatisierung der Transformationen zwischen den Ebenen eine essentielle Rolle. Der Ablauf der Entwicklung ist iterativ und beginnt mit der Ableitung der PIM-Elemente aus den fachlichen Anforderungen. Anhand von Use Cases und fachlichen Grundkonzepten (Key Abstractions) werden Business Activities und Business Entities identifiziert, welche dann zu kohäsiven Business Components gruppiert werden. Die Definition der Business Component Interfaces als Außenschnittstellen der Komponenten wird aus den resultierenden Business Facades abgeleitet. Nach der Modellierung des PIM wird der Entwicklungsprozess (siehe Abbildung 3) mit der automatischen Transformation in das plattform-spezifische PSM fortgesetzt, welches mit technischen Aspekten verfeinert und anschließend durch eine Transformation auf Source Code abgebildet wird. Dieser Prozess wird iterativ durchlaufen, wobei zu beachten ist, dass fachliche Änderungen (z.B. Hinzufügen von Methoden in Business Activities) ausschließlich im PIM durchgeführt werden. Die iterative Transformation des PIM aktualisiert das PSM und den Code ohne Beeinträchtigung existierender Elemente. Die technische Umsetzung der Modelltransformationen erfolgt in der CA durch einen in Java implementierten PIM-PSM Transformator (derzeit integriert in Borland Together), welcher das modellierte PIM ausliest und die entsprechenden PSM Elemente im UMLModell erzeugt. Ein entscheidender Punkt bei dieser Abbildung ist die Beschreibung der Transformationslogik, welche die Erzeugung der PSM-Elemente aus den jeweiligen PIM-Elementen regelt. Die CA verwendet hier den Ansatz der Meta-Modellierung, bei dem die Transformationslogik selbst in UML modelliert wird. Diese Umsetzung stellt aufgrund ihrer leichten Anpassbarkeit und Erweiterbarkeit eine zukunftsweisende Realisierung der Model Driven Architecture dar, welche ohne proprietäre und meist vorlagen-basierte Skript-Sprache zur Beschreibung von Elementabbildungen implementierbar ist. Die PSM-Source Code Abbildung wird unter Verwendung des Open Source Werkzeugs xdoclet [XDOC] implementiert, welches auf Basis attribut-

109

orientierter Programmierung für die CodeGenerierung aus dem PSM für die J2EEPlattform und die verwendeten Application Server bestens geeignet ist. In seiner Gesamtheit betrachtet, stellt der CAEntwicklungsweg einen iterativen und teilautomatisierten Prozess im Sinne der Model Driven Architecture dar. Der Mehrwert der Modellierung von Anwendungssystemen wird durch die automatisierte Transformation auf technische Plattformen klar herausgestellt, was einerseits die Motivation zur Modellierung fördert und andererseits ein stets aktuelles fachliches Modell einer Anwendung als Ergebnis liefert; dies stellt einen essentiellen Vorteil bei der langfristigen Betreuung und Wartung von Systemen dar.

Modellierung PIM PIM Automatische PIM-zu-PSM Transformation PSM Verfeinerung PSM PSM' Automatische PSM -zu-Code Transformation Source Code

Implementierung

Abbildung 3: Modellierung mit der CA

4 Erfahrungsberichte und Ausblick Als großer Vorteil der CA wurde in Projekten die einheitliche Designsprache gewertet. Mit dem Modellierungsprofil der CA ist es möglich, auch in der fachlichen Modellierung eine gemeinsame Sprache innerhalb eines Teams zu benutzen, was insbesondere den Einstieg neuer Projektmitglieder erleichtert. Die mangelnde Werkzeugunterstützung und fehlende Standardisierung der Austauschformate von Modellen erschweren jedoch die Umsetzung einer generativen Lösung. Für die Realisierung der CA war deshalb die Realisierung von Modelltransformatoren erforderlich. Erste Projekterfahrungen haben gezeigt, dass sich die technische Umsetzung durch Integration in ein UML-Werkzeug gut einsetzen lässt. Die MDA ist ein vielversprechendes Konzept für die Softwareentwicklung und bereits heute praktisch einsetzbar. Hierfür ist es jedoch notwendig, den Ansatz mit pragmatischen Konzepten geeignet zu interpretieren. So ist es heute kaum praktisch umsetzbar, Algorithmen in Diagrammen zu modellieren, um daraus eine vollständige Code-Generierung zu erreichen. Durch die Erzeugung von Code-Gerüsten ergeben sich jedoch bereits signifikante Vorteile für die anschließende Implementierung der Fachlichkeit. Für die Zukunft vielversprechend ist die UML 2.0, da sie hinsichtlich der MDA deutliche Verbesserungen bringt (z.B. UML-Profile, Modellaustausch mit XMI).

Literaturverzeichnis [ACM01]Alur, D.; Crupi, J.; Malks, D.: Core J2EE Patterns – Best Practices and Design Strategies, Sun Microsystems, California, 2001. [MM03] Miller, J.;Mukerji, J. (Editors): MDA Guide Version 1.0.1, OMG Dokument omg/2003-06-01. Object Management Group, 2003. [XDOC] xdoclet Homepage, http://xdoclet.sourceforge.net.

110