Inhaltsverzeichnis

Abk  ürzungsverzeichnis  I

Abbildungsverzeichnis   IV

1.  Einleitung  1

2.  Softwareentwicklung  3

2.1.  Einführung  3

2.2.  Objektorientierte Softwareentwicklung  5

2.3.  Komponentenstandards  6

2.3.1.  Java 2 Enterprise Edition / Enterprise Java Beans  7

2.3.2.  CORBA Component Model (CCM)  10

2.3.3.  DCOM  13

2.4.  Übergang zur modellzentrierten Softwareentwicklung  15

3.  Model Driven Architecture  17

3.1.  Überblick  17

3.2.  Definition  17

3.3.  Ziele  20

3.4.  Begriffsbestimmung  22

3.5.  Darstellung des Architektur-Frameworks  25

3.5.1.  Überblick  25

3.5.2.  UML  25

3.5.2.1.  Überblick  25

3.5.2.2.  Klassendiagramm  27

3.5.2.3.  Anwendungsfalldiagramm  31

3.5.2.4.  Sequenzdiagramm  34

3.5.2.5.  Kollaborationsdiagramm  35

3.5.2.6.  Zustandsdiagramm  36

3.5.2.7.  Aktivitätsdiagramm  39

3.5.2.8.  Komponentendiagramm  41

3.5.2.9.  Verteilungsdiagramm  41

3.5.2.10.  Object Constraint Language (OCL)  42

3.5.2.11.  Erweiterungsmöglichkeiten  44

- 2 -2

3.5.2.12.  Das UML-Metamodell  47

3.5.2.13.  Modellierung und Codegenerierung  48

3.5.3.  Weitere OMG-Standards zur Implementierung der MDA  52

3.5.3.1.  MOF  52

3.5.3.2.  XMI  53

3.5.4.  Modellebenen  55

3.5.4.1.  Plattformunabhängiges Modell  55

3.5.4.2.  Plattformspezifisches Modell  58

3.5.4.3.  Code Model  62

3.5.5.  Transformation der Modellebenen  64

3.5.5.1.  Erzeugen der plattformspezifischen Modelle  67

3.5.5.2.  Erzeugen des Code-Modells  74

3.5.5.3.  Anforderungen an Modelltransformationen  79

3.5.5.4.  Synchronisierung von Modellen und Code  81

3.5.5.5.  Enwurfsmuster/Standardkonformität  82

3.6.  Softwareentwicklungsprozess in der MDA  83

3.7.  MDA-Werkzeuge  85

3.8.  Fazit  87

4.  Praxisprojekt/Umsetzung  89

4.1.  Überblick  89

4.2.  Technische Plattform / Java 2 Enterprise Edition  89

4.2.1.  Enterprise Java Beans  90

4.2.2.  Java Server Pages/Servlets  98

4.2.3.  Struts-Framework  99

4.3.  MDA-Entwicklungsumgebung OptimalJ  101

4.4.  MDA-Entwicklungsprozess  104

4.4.1.  Fachkonzept  104

4.4.2.  Objektorientierter Entwurf  106

4.4.2.1.  Interaktion der Benutzer mit dem System - Anwendungsfälle  106

4.4.2.2.  Statische Struktur des Systems - Klassendiagramm  108

4.4.2.3.  Verhalten des Systems - Aktivitätsdiagramme  110

4.4.3.  Realisierung  116

4.4.3.1.  Abbildung des plattformunabhängigen Modells in OptimalJ  116

4.4.3.2.  PSM Datenbankschicht  117

4.4.3.3.  PSM Applikations-/Geschäftslogik  119

- 3 -3

4.4.3.4.  PSM Präsentationsschicht  121

4.4.3.5.  Inkrementelle Überarbeitung des Modells  126

4.4.3.6.  Manuelle Erweiterung der generierten Applikation  128

4.4.3.7.  Implementierung  131

4.5.  Fazit  131

5.  Schluß  133

5.1.  Zusammenfassung  133

5.2.  Ausblick  134

Literaturverzeichnis   i

Anhang xi   

- 4 -4

Abkürzungsverzeichnis

ACL Access Control Lists API Application Programming Interface ASCII American Standard Code for Information Interchange BMP Bean Managed Persistence BNF Backus-Naur-Form CCM CORBA Component Model CIDL Component Implementation Definition Language CIF Component Implementation Framework CLSID Class Identifier CMP Container Managed Persistence CMR Container Managed Relationship COM Component Object Model CORBA Common Object Request Broker Architecture CPM Container Programming Model CRUD Create Retrieve/Read Update Delete DBMS Datenbankmanagementsystem DCL Data Control Language DCOM Distributed Component Object Model DDL Data Definition Language DML Data Manipulation Language DTD Document Type Definition EDOC Enterprise Distributed Object Computing EJB Enterprise Java Bean GIOP General Inter-ORB Protocol GUI Graphical User Interface HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IDL Interface Definition Language IID Interface Identifier IIOP Internet Inter-ORB Protocol

I - I -I

ISO International Standardization Organization J2EE Java 2 Enterprise Edition J2SE Java 2 Standard Edition JAAS Java Authentication and Authorization Service JAF JavaBeans Activation Framework JAXP Java API for XML Processing JDBC Java Database Connectivity JMS Java Message Service JNDI Java Naming and Directory Interface JSP Java Server Pages JTA Java Transaction API LDAP Lightweight Directory Access Protocol MDA Model Driven Architecture MIDL Microsoft Interface Definition Language MOF Meta Object Facility MVC Model View Controller NDS Novell Directory Services OCL Object Constraint Language ODBC Open DataBase Connectivity OMG Object Management Group OMT Object Modeling Technique OOSE Object Oriented Software Engineering ORB Object Request Broker PC Personal Computer PDA Personal Digital Assistant PIM Platform Independent Model PSM Platform Specific Model QoS Quality of Service QVT Query / Views / Transformations RDBMS Relationales Datenbankmanagementsystem RMI Remote Method Invocation RMS Reklamationsmanagementsystem RUP Rational Unified Process

II - II -II

SCM Service Control Manager SDK Software Development Kit SOAP Simple Object Access Protocol SPEM Software Process Engineering Model SQL Structured Query Language SSL Secure Socket Layer TCP/IP Transmission Control Protocol/ Internet Protocol UML Unified Modeling Language WML Wireless Markup Language XMI XML Metadata Interchange XML Extensible Markup Language XP Extreme Programming XSL Extensible Stylesheet Language XSLT Extensible Stylesheet Language for Transformations

III - III -III

Abbildungsverzeichnis   

ABBILDUNG  1: J2EE ARCHITEKTUR.  

ABBILDUNG  2: CORBA UND DAS CORBA COMPONENT MODEL (CCM)  

ABBILDUNG  3: DISTRIBUTED COMPONENT MODEL (DCOM)  

ABBILDUNG  4: ABSTRAKTIONSEBENEN.  

ABBILDUNG  5: ARCHITEKTUR- UND TRANSFORMATIONSEBENEN.  

ABBILDUNG  6: KLASSENDIAGRAMM  

ABBILDUNG  7: ANWENDUNGSFALLDIAGRAMM.  

ABBILDUNG  8: SEQUENZDIAGRAMM  

ABBILDUNG  9: KOLLABORATIONSDIAGRAMM  

ABBILDUNG  10: ZUSTANDSDIAGRAMM  

ABBILDUNG  11: AKTIVITÄTSDIAGRAMM.  

ABBILDUNG  12: VERTEILUNGS- UND KOMPONENTENDIAGRAMM  

ABBILDUNG  13: AUSSCHNIT AUS DEM UML-METAMODELL.  

ABBILDUNG  14: UML-DIAGRAMMZUSAMMENHANG  

ABBILDUNG  15: 4-EBENEN METAMODELL.  

ABBILDUNG  16: PLATFORM INDEPENDENT MODEL (PIM)  

ABBILDUNG  17: PSM - DATENBANK  

ABBILDUNG  18: EJB-PSM  

ABBILDUNG  19: CODE-MODELL.  

ABBILDUNG  20: TRANSFORMATIONEN DER MDA-MODELLEBENEN  

ABBILDUNG  21: TRANSFORMATIONDEFINITION FÜR KLASSEN UND ASSOZIATIONEN.  

ABBILDUNG  22: OBJEKTRELATIONALES MAPPING - ABBILDUNG VON VERERBUNG.  

ABBILDUNG  23: TRANSFORMATIONSANSÄTZE  

ABBILDUNG  24: MDA ENTWICKLUNGSPROZESS.  

ABBILDUNG  25: REMOTE METHOD INVOCATION  

ABBILDUNG  26: EJB ENTITY BEAN IM EJB-CONTAINER  

ABBILDUNG  27: EJB-BEAN, HOME UND REMOTE INTERFACE.  

IV  - IV  

ABBILDUNG  28: JAVA SERVLET UND JAVA SERVER PAGES.  

ABBILDUNG  29: STRUTS MVC-PATTERN.  

ABBILDUNG  30: DARSTELLUNG DER ROLLEN UND ANWENDUNGSFÄLLE.  

ABBILDUNG  31: KLASSENDIAGRAMM DER APPLIKATION.  

ABBILDUNG  32: ANLEGEN EINES OBJEKTES  

ABBILDUNG  33: AUSWAHL EINES OBJEKTES ZUR ANZEIGE, BEARBEITUNG ODER ZUM ENTFERNEN.  

ABBILDUNG  34: BEARBEITEN , ANZEIGEN ODER ENTFERNEN EINES OBJEKTES.  

ABBILDUNG  35: AKTIVITÄT "SPRACHE WECHSELN"  

ABBILDUNG  36: AKTIVITÄTSDIAGRAMM ABONNEMENT  

ABBILDUNG  37: AKTIVITÄTSDIAGRAMM KUNDENREPORT SENDEN  

ABBILDUNG  38: DATENBANK-PSM  

ABBILDUNG  39: EJB-PSM  

ABBILDUNG  40: WEB-PSM.  

ABBILDUNG  41: SICHTEN PRÄSENTATIONSSSCHICHT.  

ABBILDUNG  42: WEB-PSM: STRUTS-PRÄSENTATIONSSCHICHT.  

ABBILDUNG  43: STRUTS-CONFIG  

ABBILDUNG  44: HINZUFÜGEN EINES ATTRIBUTS  

ABBILDUNG  45: ERZEUGUNG DES REKLAMATIONSREPORTS MIT HILFE EINER SESSIONFACADE.  

ABBILDUNG  46: OBJEKT-RELATIONALES MAPPING: ASSOZIATIONEN  

V  - V  

Einleitung 1

1. Einleitung

Die Entwicklung betrieblicher Anwendungssysteme ist durch eine zunehmende Komplexität und Heterogenität der technischen Plattformen und die Anforderung der Integration voneinander unabhängiger Softwarekomponenten gekennzeichnet. Gleichzeitig ist eine steigende Bedeutung der Informationstechnologie für die strategische Entwicklung eines Unternehmens festzustellen. Dies erhöht die Anforderungen an die Qualität und Langlebigkeit von Anwendungssystemen unter der Berücksichtigung der bei der Entwicklung auftretenden Kosten.

Das von der Object Management Group (OMG) entwickelte Konzept der Model Driven Architecture (MDA) stellt den Versuch dar, einen einheitlichen Standard zur Anwendung modellzentrierter Softwareentwicklung zu etablieren und durch Formalisierung der abzubildenden Geschäftslogik eine Automatisierung der Softwareentwicklung zu ermöglichen. Durch die Verwendung modellzentrierter Softwareentwicklung kann die Produktivität der Softwareerstellung durch kürzere Entwicklungszeiten erhöht werden. ¹ Gleichzeitig soll durch Trennung unterschiedlicher konzeptioneller Modellebenen eine Entkopplung des Softwareentwurfs von der zugrundeliegenden Technologieplattform erfolgen. Hierdurch werden Eigenschaften wie Portabilität und Wiederverwendbarkeit von Software adressiert.

In der vorliegenden Arbeit sollen die Basiskonzepte und Ziele der Model Driven Architecture (MDA) erläutert werden. Der Modellzentrierung wird durch eine eingehende Betrachtung der Modellierungsnotation UML im Umfeld der Model Driven Architecture Rechnung getragen. Möglichkeiten der generativen Softwareentwicklung durch Transformation von Softwaremodellen in Quellcode stellen ein weiteres Kernkonzept der MDA dar und werden anhand eines Beispiels ausführlich erläutert. Grundlagen der Softwareentwicklung sowie der Konzepte verteilter Systeme und Komponentenstandards sollen der Einordnung der modellzentrierten

Softwareentwicklung mit Hilfe der MDA dienen. Die praktische Umsetzbarkeit der Model Driven Architecture wird im Rahmen der praktischen Erstellung eines

Vgl. o.V.: Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) 1

Approach - Productivity Analysis, Online im Internet: http://www.middleware-

company.com/casestudy/mda.pdf, S. 9 ff.

Einleitung 2

Softwareprotoypen demonstriert. Hier wird auch einer der Eingangs vorgestellten Komponentenstandards näher erläutert, um die technischen Grundlagen des Softwareprototypen zu skizzieren.

In der Arbeit auftretende Quellcode-Beispiele, XML-Auszeichnungen sowie buchstabengetreue Wiedergaben werden in Nichtproportionalschrift

wiedergegeben, Ebenso Verweise auf Klassen, Attribute und Operationen. Gerade betrachtete Code-Ausschnitte werden in Nichtproportionalschrift fett hervorgehoben.

Model Driven Architecture 3

2. Softwareentwicklung

2.1. Einführung

Softwareentwicklung hat die Aufgabe ein Softwareprodukt „zu planen, zu definieren, zu entwerfen und zu realisieren, das die geforderten Qualitätseigenschaften besitzt und die Kundenwünsche erfüllt“ ² . Sie ist dabei heute als ingenieursmäßige, arbeitsteilige Entwicklung komplexer Software-Systeme zu verstehen, die sich etablierter Prinzipien, Werkzeuge und Methoden bedient. 3

Phasen der Softwarentwicklung umfassen in chronologischer Abfolge die Projektbegründung, die Systemanalyse, den Systementwurf, die Realisierung und die Einführung des Softwaresystems. Die Projektbegründung definiert die Notwendigkeit zur Entwicklung eines Softwaresystems. Die Phase der Systemanalyse, umfasst die Ermittlung des Istzustandes und die Definition eines fachlichen Grobentwurfs, in dem die Anforderungen der Zielanwender Berücksichtigung finden. Der Systementwurf

überführt die in der Systemanalyse definierten Anforderungen in eine technische Programmspezifikation, die in der Phase der Realisierung in eine konkrete Anwendung übersetzt wird. Die Phase der Realisierung umfasst darüber hinaus das Testen der erstellten Softwareartefakte, um anschließend das Softwareprodukt für den Produktiveinsatz freigeben zu können. 4

Es existieren Vorgehensmodelle, die eine abstrakte Beschreibung der zur Erstellung eines Softwareproduktes erforderlichen Schritte darstellen und den bei den einzelnen Schritten erforderlichen Einsatz von Methoden und Werkzeugen definieren. ⁵ Das Wasserfallmodell als das einfachste Vorgehensmodell entspricht der sequentiellen Bearbeitung der oben aufgeführten Phasen der Softwareentwicklung. Ergebnisse der einzelnen Phasen gehen

Balzert, Helmut: Lehrbuch der Software-Technik - Software-Entwicklung, 2. Aufl., Heidelberg, 2

Berlin 2001, S. 39 Vgl. ebenda, S. 36 ³ Vgl. ebenda, S. 213 ff. 4

Vgl. Stahlknecht, Peter; Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik, 10. Aufl. 5

Berlin u.a. 2002, S. 219

Model Driven Architecture 4

als unveränderliche Anforderungen in die nächste Phase ein, Rücksprünge sind nicht erlaubt. ⁶ Das V-Modell ist der Entwicklungsstandard für IT-Systeme der Bundesbehörden. Phasen der Anfoderungsanaylse, des Entwurfs und der Implementierung werden im V-Modell mit Massnahmen der Qualitätssicherung gekoppelt, die über ausführliche Dokumentationen und Tests die vorangegangenen Phasen validieren. ⁷ Neben der Systementwicklung inkl. Qualitätssicherung deckt das V-Modell Aspekte wie das Konfigurations- und Projektmanagement ab. Der unter Zuhilfenahme der UML abzubildende Rational Unified Process (RUP) stellt ein objekt-orientiertes Vorgehensmodell dar, das auf der graphischen Softwaremodellierung unter Verwendung von Softwareentwicklungswerkzeugen beruht. Die Softwaremodelle ersetzen die in schwergewichtigen Prozessen wie dem V-Modell üblichen umfangreichen Softwaredokumentationen. Der RUP basiert neben der Modellierung von Software auf den Konzepten der inkrementell-iterativen Entwicklung, der Verwendung komponentenbasierter Softwarearchitekturen und einem Anforderungs- und Änderungsmanagement. ⁸ Neuere Verfahren wie das Xtreme Programming (XP) verzichten hingegen auf die Erstellung detaillierter Anforderungskataloge, da sie davon ausgehen, dass sich einige Anforderungen erst im Laufe des Entwicklungsprozesses ergeben. XP basiert daher auf einem prototypischen Vorgehen, das schnell auf Änderungswünsche reagieren kann, Dokumentation auf die Ebene des Quelltextes reduziert und ständige Testläufe, kurze Integrationszyklen, Programmieren in Paaren und laufende Refaktorierung des Softwaresystems propagiert. 9

Vgl. Fink, Andreas; Schneidereit, Gabriele; Voß, Stefan: Grundlagen der Wirtschaftsinformatik, 6

1. Aufl., Heidelberg 2001, S. 167

Vgl. Bröhl, Adolf-Peter; Dröschel, Wolfgang: Das V-Modell, 1. Aufl., München u.a. 1993, S. 23 ff. 7

Vgl. Gornik, Davor: IBM Rational Unified Process: Best Practices for Software Development 8

Teams, Online im Internet: http://www3.software.ibm.com/ibmdl/pub/software/

rational/web/whitepapers/2003/rup_bestpractices.pdf, S. 3 f. Vgl. o.V.: The Rules and Practices of Extreme Programming, Online im Internet 9

http://www.extremeprogramming.org/rules.html

Model Driven Architecture 5

2.2. Objektorientierte Softwareentwicklung

Die Phasen der Analyse und des Entwurfs sind gekennzeichnet von dem der konkreten Softwareentwicklung zugrundeliegenden Paradigma. Die strukturierte

Systementwicklung, bzw. das strukturierte Paradigma basiert auf der getrennten Betrachtung von Prozessen, Funktionen und Daten. Das abzubildende Softwaresystem wird dabei in einzelne Module zerlegt, die Funktionen des Gesamtsystems repräsentieren. Zur Analyse des Systems kann das Gesamtsystem in einer top-down Vorgehensweise in Teilsysteme zerlegt werden. Ausgehend von den einzelnen identifizierten Funktionen, kann die Realisierung des Gesamtsystems durch Aggregation der Einzelfunktionen und Module zum Gesamtsystem vorgenommen werden (bottom-up Vorgehensweise). Die strukturierte Systemenwtwicklung kennt verschiedene definierte Verfahren (etwa die „Strukturierte Analyse“, den „Strukturierten Entwurf“) und Darstellungsformen, zur Abbildung von Funktionen, Prozessen (Petri-Netze, Nassi-Shneiderman-Diagramme etc.) und Daten (Entity-Relationship-Diagramm). 10

Das Aufkommen objektorientierter Programmiersprachen seit Ende der 60er Jahre begründet das sog. objektorientierte Paradigma, bei dem Analyse, Entwurf und Realisierung an der Definition von Objekten ausgerichtet sind. Im Gegensatz zur strukturierten Systementwicklung beinhaltet die Definition von Objekten, die durch Eigenschaften und Verhalten gekennzeichnet sind die integrierte Betrachtung von Funktionen und Daten. ¹¹ Objekte repräsentieren eigenständige Ausführungseinheiten, die parallel ausgeführt werden können. ¹² Objektorientierung ist durch die Konzepte der Kapselung (Zusammenfassung von Daten (Variablen) und darauf operierenden Methoden), Abstraktion (Beschreibung gleichartiger Objekte durch Klassen), Wiederverwendung (Beschreibung von Schnittstellen der Klassen durch Interfaces ermöglicht die einfache Benutzung der durch die Schnittstelle spezifizierten

Vgl. Stahlknecht, Peter; Hasenkamp, Ulrich: a.a.O., S. 258 ff. 10

Vgl. Brookshear, J. Glenn: Computer science: An Overview, 1. Aufl., Reading 2000, S. 234 11

Vgl. Poetzsch-Heffter, Arnd: Konzepte objektorientierter Programmierung, 1. Aufl., Berlin u.a. 12

2001, S. 16

Model Driven Architecture 6

Funktionalität) und Vererbung (Klassen können Eigenschaften und Verhalten anderer Klassen erben und ggf. durch Überschreiben anpassen) gekennzeichnet. 13

Die Unified Modelling Language (UML) hat sich seit Ende der 90er Jahre als Notationsstandard für das objektorientierte Paradigma durchgesetzt und bietet verschiedene Diagrammtypen, die im Rahmen der objektorientierten Analyse, des Entwurfs und der Implementierung eingesetzt werden können.

2.3. Komponentenstandards

Softwaresysteme lassen sich vielfach einer der folgenden drei Kategorien zuordnen: Einzelplatzsysteme bieten Benutzern die Möglichkeit Programme auf einem Rechner auszuführen, der unabhängig von anderen Systemen agiert. Beispiele sind Textverarbeitung oder Multimediaanwendungen auf PCs. Eingebettete Systeme umfassen Steuerungssysteme für Geräte, aber auch Anwendungen in Mobiltelefonen oder PDAs. Verteilte Systeme schließlich erlauben die Verteilung von Software und Informationsverarbeitung sowohl auf unterschiedliche durch ein Netzwerk verbundene Rechner, als auch auf verschiedene Schichten innerhalb eines Anwendungsystems. ^14,15 Für den Benutzer bleibt die tatsächliche Verteilung dabei verborgen.

Verteilte objektbasierte Systeme bedienen sich der Anwendung komponentenbasierter Softwareentwicklung, die versucht durch die Trennung von Zuständigkeiten die Entwicklung der Geschäftslogik von der technischen Infrastruktur zu trennen und so „den Anwendungskontext in den Vordergrund zu rücken“ ¹⁶ . Software-Komponenten sind dabei Software-Bausteine, die eine Funktionalität anbieten und über standardisierte Schnittstellen angesprochen in Softwaresystemen eingesetzt werden können. 17

Vgl. Krüger, Guido: Handbuch der Java-Programmierung, 3. Auflage, München u.a. 2003, S. 143 13

ff.

Vgl. Sommerville, Ian: Software Engineering, 6. Aufl., München 2001, S. 249 14

Vgl. Andresen, Andreas: Komponentenbasierte Softwareentwicklung mit MDA, UML und 15

XML, 1. Aufl. München, Wien 2003, S. 2 Vgl. ebenda, S. 1 16

Vgl. Griffel, Frank: Componenteware - Konzepte und Techniken eines Softwareparadigmas, 1. 17

Aufl., Heidelberg 1998, S. 31

Model Driven Architecture 7

Der Austausch zwischen einzelnen Komponenten und den zugrundeliegenden Betriebssystemen wird über sog. Middleware geleistet. Middleware ist dabei als Schicht zwischen Applikationen und Betriebssystemen ¹⁸ zu verstehen, die Softwareentwicklern einen höherwertigen, abstrakten Zugriff auf Dienste wie Transaktionen, Nachrichtenaustausch oder entfernte Methodenaufrufe bietet. ¹⁹ Neben auf spezifische Dienste ausgerichtete Middleware exisitieren verschiedene Komponentenstandards, die neben der Syntax der einzusetzenden Komponenten, Dienste zur Erzeugung, Aktivierung oder Deaktivierung von Komponenten oder Transaktions-, Persistenz- und Sicherheitsdienste definieren, die eine Laufzeitumgebung für Komponenten bereitstellen muss. Komponentenstandards legen damit neben der Nutzung von Middleware zur Kommunikation von Komponenten, Laufzeitumgebungen für Komponenten fest, die in Form von Applikationsservern/-containern diese spezifischen Dienste bereitstellen. 20

Zu den bekanntesten Komponentenstandards gehören die auf der Programmiersprache Java basierende Java 2 Enterprise Edition mit dem Komponentenmodell Enterprise Java Beans, das CORBA Component Model (CCM) und die Microsoft Windows basierte COM+-Architektur. 21

2.3.1. Java 2 Enterprise Edition / Enterprise Java Beans

Die Java 2 Enterprise Edition (J2EE) ist das von Sun Microsystems definierte Rahmenwerk zur modularen Entwicklung komponentenbasierter Unternehmensanwendungen. Die J2EE basiert auf der Java 2 Standard Edition und definiert eine verteilte, mehrschichtige und Java-basierte Anwendungsarchitektur, welche die Implementierung von unternehmensweiten Anwendungen und Middleware-Diensten innerhalb eines

Bei verteilten Systemen erstreckt sich die Middleware-Schicht dabei über mehrere Rechner. 18

Vgl. Emmerich, Wolfgang: Konstruktion von verteilten Objekten, 1. Aufl., Heidelberg 2003, S. 86 19

f.

Vgl. Andresen, Andreas: a.a.O., S. 255 f. 20

Vgl. Andresen, Andreas: a.a.O.S. 257 ff. 21

Model Driven Architecture 8

definierten Rahmens ermöglichen soll. J2EE dient dabei originär der Realisierung großer, verteilter Softwaresysteme. 22

Bestandteile des J2EE-Frameworks sind Technologien wie Java Server Pages und Servlets zur Realisierung webbasierter Benutzerschnittstellen, Enterprise Java Beans als Middlewarebasierte Komponentenplattform zur Implementierung von Geschäfts- und Datenzugriffslogik sowie Java-Applikationen und Java-Applets zur Abbildung plattformunabhängiger Softwareanwendungen. Das Hauptmerkmal des J2EE Modells besteht dabei in der Systematik, einfach zu konfigurierende und anpassbare Softwarekomponenten durch Definition von Ausführungsumgebungen (Container) zu ermöglichen, die Systemdienste (Transaktionen, Sicherheitsmechanismen, etc.) und Programmierschnittstellen (API) bereitstellen. ²³ Die der J2EE Plattform zugrunde liegende Spezifikation ²⁴ erlaubt dabei Anbindungen der J2EE Anwendung an bereits vorhandene Legacy-Systeme. Die Bereitstellung von systemnahen Diensten soll den Anwendern die Fokussierung auf die Planung und Programmierung der eigentlichen Geschäftslogik ermöglichen und damit die Zeit von der Planung bis zur Marktreife der Software verkürzen.

Die J2EE Plattform ist kein Produkt im engeren Sinne, die zugrundeliegende J2EE Spezifikation ermöglicht es vielmehr, zu der Plattform kompatible Produkte zu entwickeln, die dann die Basis für J2EE Anwendungen bilden. Neben der J2EE Spezifikation, welche die Architektur, sowie umzusetzende APIs und Konventionen definiert, umfasst die J2EE Plattform eine J2EE Referenzimplementation inkl. einer umfangreichen Klassenbibliothek (J2EE SDK) zur Entwicklung von J2EE Komponenten, sog. „Blue Prints“, die Strategien zur effizienten Umsetzung von J2EE Anwendungen

Vgl. Shannon, Bill: Java 2 Platform Enterprise Edition Specification, v1.4, Online im Internet: 22

http://java.sun.com/j2ee/1.4/download.html#platformspec (PDF), S. 13 ff. Vgl. Juric, Matjaz B. et al.: Professional J2EE EAI, 1. Aufl. Birmingham 2001, S. 112 f. ²³ Siehe Java 2 Platform Enterprise Edition Specification, v1.4: 24

http://java.sun.com/j2ee/1.4/download.html#platformspec

Model Driven Architecture 9

beschreiben ²⁵ , sowie ein „Application Verification Kit“ zur Validierung von J2EE-Applikationen ²⁶ .

Abbildung 1: J2EE Architektur

Quelle: Entworfen und gezeichnet: Verfasser

Abbildung 1 zeig die grundlegenden Bestandteile der J2EE-Architektur. Enterprise Java Beans (EJBs) stellen die serverseitige Komponententechnologie der Java 2 Enterprise Edition dar. Die von Sun herausgegebene EJB Spezifikation definiert die Struktur, Schnittstellen und notwendigen Bestandteile der EJBs sowie die von EJB-Containern zur Verfügung zu stellenden Funktionaliäten. Die Container werden von Applikationsservern bereitgestellt, die die Laufzeitumgebung für die einzelnen Komponenten darstellen und diese kapseln. Der Container ermöglicht die Persistenzverwaltung von Objekten die in Datenbanken gespeichert werden und steuert den Lebenszyklus der einzelnen Komponenten. Darüber hinaus werden Systemdienstleistungen wie

Siehe http://java.sun.com/blueprints/enterprise/index.html 25

Siehe http://java.sun.com/j2ee/verified/avk_enterprise.html 26

Model Driven Architecture 10

Transaktionsmanagement („Container Managed Transaction“), Sicherheitsmechanismen oder Ressource-Pooling zur Verfügung gestellt. ²⁷ Über Konnektoren besteht darüber hinaus die Möglichkeit auf weitere externe Systeme zuzugreifen, sofern diese das J2EE Konnektor Modell unterstützen. ²⁸ Anwendungsprogrammierer, die Applikationen für die J2EE Plattform entwickeln, haben vollen Zugriff auf alle APIs und Protokolle, die die Java 2 Standard Plattform zur Verfügung stellt.

2.3.2. CORBA Component Model (CCM)

Die Common Object Request Broker Architecture (CORBA) ist eine von der Object Management Group (OMG) ²⁹ entwickelte Spezifikation, die eine objektorientierte Middleware beschreibt, welche plattformübergreifende Protokolle und Dienste definiert. ³⁰ CORBA adressiert die Entwicklung verteilter Anwendungen in heterogenen Umgebungen. ³¹ CORBA ist somit nicht an eine bestimmte Programmiersprache gebunden. Mit Hilfe eines Object Request Brokers und einer

programmiersprachenneutralen Schnittstellendefinitionssprache (Interface Definition Language (IDL)) werden Objekte definiert und Objektanfragen weitergeleitet. Über die IDL kann eine abstrakte Spezifikation der von einem Objekt bereitgestellten Funktionalität inkl. der Ein- und Ausgabeparemter der Operation aber auch von Ausnahmen und Datentypen erstellt werden. ³² Diese Schnittstellenbeschreibung wird dann mit Hilfe eines IDL-Kompilers in das Objektmodell der verwendeten Programmiersprache umgesetzt („language mapping“). ³³ Der IDL-Kompiler erzeugt

Vgl. ausführlich Abschnitt 4.2.1 oder Monson-Haefel, Richard: Enterprise Java Beans, Deutsche 27

Ausgabe der 3. Auflage, Sebastopol u.a. 2002, S. 31 f. Siehe. http://java.sun.com/j2ee/white/connector.html ²⁸ Vgl. Abschnitt 3.1 29

Vgl. Merz, Michael: E-Commerce und E-Business, 2. Aufl., Heidelberg 2002, S. 318 30

Vgl. Siegel, John: CORBA 3 Fundamentals & Programming, 2. Aufl., New York u.a. 2000, S. 2 f. ³¹ Vgl. ebenda S. 61 f. 32

Dabei werden IDL-Konstrukte auf die entsprechenden Konstrukte der Zielsprache gemappt. Es 33

exisitieren Mapping-spezifikationen u.a. für C, C++, Java, Smalltalk, COBOL oder Ada. Vgl.

http://www.omg.org/technology/documents/formal/corba_language_mapping_specs.htm

Model Driven Architecture 11

darüber hinaus Stubs und Skeletons. Diese Vertreter-Objekte nehmen Anfragen des Klienten entgegen (Stub) leiten sie über die Object Request Broker (ORB) auf Client- und Serverseite weiter und rufen die gewünschten Methoden an der eigentlichen Objektimplementation auf (Skeleton). ³⁴ Der Object Request Broker ermöglicht die transparente Kommunikation von Objekten auf verteilten Systemen, indem er Methodenaufrufe entgegennimmt und an die entsprechenden Objekte weiterleitet. ³⁵ IDLs werden in einem IDL-Repository abgelegt, das so die Interoperabilität unterschiedlicher ORB ermöglicht, die Zugriff auf die gemeinsamen Schnittstellendefinitionen haben (vgl. Abbildung 2).

Um ORBs unterschiedlicher Hersteller kommunizieren zu lassen, wurde mit der Version 2.0 der CORBA-Spezifikation das General Inter-ORB Protocol (GIOP) definiert, das die Kommunikation der Object Request Broker für verschiedene Transportprotokolle festlegt. Am weitesten verbreitet ist der Einsatz des GIOP über TCP/IP, in der Form des Internet Inter-ORB Protokols (IIOP). 36

Zusätzlich zu Protokollen und IDL-Definitionen definiert CORBA noch einige Dienste (Services). Hierzu zählen Sicherheits-, Persistenz, Transaktions-, Nebenläufigkeits- und Namensdienste. 37

Vgl. Otte, Randy et al.: Understanding CORBA, 1. Aufl., Upper Saddle River 1996, S. 3-7 f. 34

Vgl. Puder, Arno; Römer, Kay: Middleware für verteilte Systeme, 1. Aufl. Heidelberg 2001, S. 43 35

Vgl. o.V.: CommonObject Request Broker Architecture: Core Specification, Online im Internet: 36

http://www.omg.org/cgi-bin/apps/doc?formal/02-12-06.pdf, S. 15-1 Vgl. Merz, Michael: a.a.O., S 321 f. 37

Model Driven Architecture 12

Abbildung 2: CORBA und das CORBA Component Model (CCM)

Quelle: Entworfen und gezeichnet: Verfasser

Auf CORBA basierend hat die OMG die Spezifikation eines CORBA Component Models (CCM) definiert. Neben dem eigentlichen Komponentenmodell besteht CCM aus einem Component Implementation Framework (CIF), einer Component Implementation Definition Language (CIDL) und einem Container Programming Model. 38

Das Komponentenmodell legt den Aufbau von CORBA-Komponenten, ihre Eigenschaften und Schnittstellen und Konfigurationsdetails zur Verteilung und Installation von Komponenten fest. Die Component Implementation Definition Language beschreibt die Struktur von Komponentenimplementierungen und kann innerhalb des Implementation Frameworks eingesetzt werden um Programm-Skelette zu erzeugen, die das Basisverhalten der Komponenten festlegen. Das Container Programming Model definiert

Vgl. o.V.: CORBA Components, Online im Internet: http://www.omg.org/cgi- 38

bin/apps/doc?formal/02-06-65.pdf

Model Driven Architecture 13

die von einem CCM kompatiblen Applikationsserver bereitzustellenden API-Schnittstellen und Services, die von CORBA-Komponenten genutzt werden können. Der Container verwaltet die Komponenten, indem Instanzen erzeugt und zerstört, Client-Anfragen bedient und CORBA-Services bereitgestellt werden. 39

Die Komponentenmodelle der J2EE Spezifikation und des CCM sind einander sehr ähnlich, beide Spezifikationen definieren darüber hinaus explizit die Nutzung der jeweiligen anderen Technologie.

2.3.3. DCOM

DCOM (Distributed Component Object Model) ist das verteilte, proprietäre Komponentenmodell der Microsoft Windows Betriebssystemwelt. DCOM basiert auf dem Microsoft Component Object Model (COM) das die Entwicklung dynamisch aktivierbarer Komponenten ermöglicht. Während COM auf den lokalen Rechner beschränkt ist, fügt DCOM die Möglichkeit der Nutzung verteilter Komponenten hinzu. 40

Abbildung 3: Distributed Component Model (DCOM)

Quelle: Entworfen und gezeichnet: Verfasser

DCOM realisiert das Konzept verteilter Objekte, auf die über definierte binäre Schnittstellen zugegriffen werden kann. Die Microsoft Interface Definition Language

Vgl. Andresen, Andreas: a.a.O., S. 268 39

Vgl. Tanenbaum, Andrew; v. Steen, Marten: Verteilte Systeme, 1. Aufl., München 2003, S. 588 ff. 40

Model Driven Architecture 14

(MIDL) ermöglicht analog zu der oben beschriebenen CORBA-IDL die Definition der Schnittstellen die ein DCOM-Objekt implementiert. ⁴¹ Ein MIDL-Compiler erzeugt Proxies und Stubs sowie Code für das Konvertieren von Datentypen und das Verpacken von Aufrufanforderungen (Marshalling/Demarshalling) (vgl. Abbildung 3). 42

DCOM-Schnittstellen und Klassenobjekte haben eine global eindeutige ID (IID: Interface Identifier und CLSID: Class identifier) ⁴³ , über die DCOM-Komponenten in der lokalen Registry des Host-Rechners oder über einen Service Control Manager (SCM) auch auf entfernten System angesprochen und aufgerufen werden können. Abbildung 3 verdeutlicht die Kapselung der Komponenten, Methodenaufrufe geschehen nur indirekt über die umgebende Schicht.

DCOM stellt Dienste zur Verfügung, die Transaktionen abbilden, die Lebensdauer von Objekten steuern, Sicherheitskontrollen, Datenbankzugriffe (ODBC) und asynchrone Nachrichtenaufrufe ermöglichen, die teilweise deklarativ konfiguriert werden können. ⁴⁴ Neben reinen DCOM Diensten wird dabei auf externe Systeme (Microsoft Transaction Server, Microsoft Message Queue Server) zurückgegriffen. ⁴⁵ Dies schränkt die Interoperabilität ein, da für ein vollständiges Diensteangebot Windows-Systemdienste (bspw. der Active Directory Verzeichnisdienst) vorhanden sein müssen.

Die drei vorgestellten Komponententechnologien weisen neben strukturellen Unterschieden die folgenden Gemeinsamkeiten auf: Spezielle Laufzeitumgebungen

Vgl. Rosen , Michael; Curtis, David: Integrating CORBA and COM Applications, 1.Aufl., New 41

York u.a. 1998, S. 40 ff.

Vgl. Horstmann, Markus; Kirtland, Mary: DCOM Architecture, .Online im Internet: 42

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomarch.asp

Die 128-bit lange ID wird aus der MAC-Adresse der Netzwerkschnittstelle, einem Zeitstempel 43

und Zufallszahlen generiert. Daher kann eine globale Eindeutigkeit unterstellt werden. Etwa die Steuerung des Zugriffs über Access Control Lists (ACL) vgl. o.V. DCOM Technical 44

Overview, Online im Internet:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomtec.asp

Siehe http://www.microsoft.com/com/wpaper/compsvcs.asp#mts 45

Model Driven Architecture 15

(Container) bilden die zugrundeliegende Architektur und übernehmen die direkte Kommunikation mit den Klienten. Die Komponenten sind von außen nur über den Container erreichbar. Der Container kann so Dienste wie die Kontrolle der Zugriffsberechtigung, Transaktionen, Persistenz oder Verzeichnis- und Namensdienste zur Verfügung stellen.

2.4. Übergang zur modellzentrierten Softwareentwicklung

Die Verwendung middlewarebasierter Komponenten vereinfacht die Entwicklung verteilter Systeme da der Anwendungsentwickler die von der Middleware angebotenen Dienste nutzen kann und nicht programmatisch umsetzen muss. Die komponentenbasierte Softwareentwicklung vereinigt zwei grundsätzliche Ansätze bei der Erstellung von Softwaresystemen: Verteilung und Abstraktion. Abstraktion ermöglicht die Trennung von Verantwortlichkeiten für technische und funktionale Abbildung von Geschäftsproblemen und die Konzentration der Anwendungsentwickler auf die eigentliche Geschäftslogik. Der Übergang von Maschinensprachen über höhere Programmiersprachen die unterschiedlichen Softwareparadigmen (funktional, objekt-orientiert, deklarativ) genügen, bis zu Komponenten-Architekturen und verteilten Systemen zeichnet sich durch eine kontinuierliche Erhöhung des Abstraktionsgrades aus. 46

Vgl. Mellor, Stephen J.; Balcer, Marc J.: Executable UML, 1. Aufl., Boston u.a. 2002, S. 2 ff. 46

Model Driven Architecture 16

Abbildung 4: Abstraktionsebenen

Quelle: in Anlehnung an: Eskelin, Phillip: http://jerry.cs.uiuc.edu/~plop/plop99

/proceedings/Eskelin2/LayeredComponentFramework.pdf, S2; Entworfen und gezeichnet:

Verfasser

Die modellzentrierte Softwareentwicklung im Rahmen der MDA kann als weitere Abstraktionsebene aufgefasst werden. Die MDA abstrahiert von den zugrundeliegenden Softwareplattformen und soll eine stärkere Fokussierung auf die Abbildung der Geschäftslogik ermöglichen. Der weiteren Erhöhung des Abstraktionslevels wird dabei ein dem Übergang von Assembler zu Hochsprachen vergleichbarer Produktivitätszuwachs nachgesagt. 47

Die MDA wird im folgenden Abschnitt 3 ausführlich dargestellt.

Vgl. o.V.: An Evaluation of Compuware OptimalJ Professinal Edition as an MDA Tool, Online 47

im Internet: http://www.itpapers.com/abstract.aspx?&view=68893&docid=68893, Stand

09.2003, S. 2

Model Driven Architecture 17

3. Model Driven Architecture

3.1. Überblick

Die Object Managament Group (OMG) ist eine internationale Organisation, die sich um Standardisierungen im Bereich der objektorientierten Softwareentwicklung bemüht. Zu den über 800 Mitgliedern aus dem Hard- und Softwarebereich zählen u.a. IBM, Sun Microsystems, Microsoft, Oracle und Siemens. Neben CORBA gehört die Modellierungssprache UML (Unified Modeling Language) zu den bekanntesten von der OMG gepflegten Standards. ⁴⁸ Die Modellierungs-Architektur ⁴⁹ der OMG umfasst darüber hinaus, neben einem Standard zur Metamodellierung (Meta-Object-Facility (MOF)) und zum Austausch von Softwarmodellen (XML Metadata Interchange (XMI)), einen Rahmenstandard zur modellbasierten Softwareentwicklung, die Model Driven Architecture (MDA), die in diesem Kapitel vorgestellt wird.

3.2. Definition

Die Model Driven Architecture definiert einen Software-Entwicklungsansatz, der eine Trennung der fachlichen von den technologischen Anforderungsspezifikationen vorsieht und der Modellierung dieser Architekturebenen im Rahmen des Software-Entwicklungsprozesses einen besonderen Stellenwert einräumt. 50

Hierzu werden unterschiedliche Modellierungsebenen abgegrenzt, die auf verschiedenen Abstraktionsstufen eine plattformunabhängige Sicht auf das abzubildende Geschäftproblem bzw. die Facharchitektur („Platform Independent Model“, PIM), eine

Siehe http://www.omg.org/news/about/index.htm 48

Siehe http://www.omg.org/technology/documents/vault#modeling 49

Vgl. de Miguel, Miguel; Jourdan, Jean; Salicki, Serge: Practical Experiences in the Application of 50

MDA in: Jézéquel, Jean-Marc; Hussmann, Heinrich; Cook, Stephen (Hrsg.): «UML» 2002 - The

Unified Modeling Language, Berlin u.a. 2002, S. 128 f.

Model Driven Architecture 18

plattformabhängige Sicht unter Berücksichtigung der Anwendungsarchitektur („Platform Specific Model“, PSM) und eine systemnahe Sicht in Form eines Code-Modells darstellen. 51

Die MDA definiert darüber hinaus Übergänge der einzelnen Modellebenen, die in Form von Transformationen die abstrakte, plattformunabhängige Sicht durch Anreicherung von zusätzlichen Informationen (Verfeinerung) über ein oder mehrere

plattformspezifische Modelle in ein ausführbares Code-Modell überführen.

Neben der klaren Trennung der Architekturebenen gilt die Kopplung der Modellebenen durch automatische Transformationen, als Kerngedanke der MDA. ⁵² Die MDA versucht so den im Verlauf eines Softwareentwicklungsprozesses häufig zu beobachtenden Bruch zwischen der Modellierung im Rahmen der Analyse und des Designs und der tatsächlichen Implementierung des Systems zu schließen ⁵³ .

Durch die definierte Trennung der Geschäfts- von der Applikationslogik wird eine Modellierung des Domänenproblems ⁵⁴ mit einem hohen Abstraktionsgrad möglich. Die Überführung in weniger abstrakte (detaillierte) Modelle kann dann von Werkzeugen übernommen werden. ^55,56 Die MDA kann somit als eine weitere Abstraktionsschicht im Rahmen der Softwareentwicklung angesehen werden (vgl. Abschnitt 2.4).

Vgl. Miller, Joaquin; Mukerji, Jishnu (Hrsg.): MDA Guide Version 1.0.1, Online im Internet, 51

http://www.omg.org/docs/omg/03-06-01.pdf, Stand 12.06.2003, Abruf: 05.10.2003, 2.2.12 (im

Folgenden zitiert als: MDA Guide)

Vgl. Kleppe, Anneke et al.: MDA Explained, 1. Aufl., Boston u.a. 2003, S. XV, sowie Ditze, 52

Andreas; Ghadir, Phillip; Tilkov, Stefan: Trennung von fachlicher und technische

Komponentenarchitektur im Sinne der MDA, in: Objektspektrum, Nr. 2 (2003), S. 65 Vgl. Sturm, Thorsten; Boger, Marko: Softwareentwicklung auf Basis der Model Driven 53

Architecture, in: Heilmann, Heidi; Strahringer, Susanne: Neue Konzepte in der

Softwareentwicklung, Praxis der Wirtschaftsinformatik, Juni 2003, S. 38 f. Vgl. zum Begriff der Domäne Abschnitt 3.4 54

Vgl. Mellor, Stephen J.; Scott, Kendall; Uhl, Axel; Weise, Dirk: Model-Driven Architecture in 55

Bruel, Jean-Michel; Bellahsène (Hrsg.): Advances in Object-Oriented Information Systems, 1.

Aufl., Berlin u.a. 2002, S. 290 f.

Eine Modellierung zweier persistenter Klassen bspw., die über eine n zu n Beziehung 56

verbunden sind (Modellierung auf hohem Abstraktionsniveau) erfordert die Transformation

Model Driven Architecture 19

Abbildung 5: Architektur- und Transformationsebenen.

Quelle: in Anlehnung an Ditze, Andreas; Ghadir, Phillip; Tilkov, Stefan: Trennung von

fachlicher und technische Komponentenarchitektur im Sinne der MDA, in: Objektspektrum,

Nr. 2 (2003), S. 63; Entworfen und gezeichnet: Verfasser

Abbildung 5 zeigt die Basiskonzepte der MDA. Hierzu gehört neben der expliziten Trennung der Modellebenen, die automatische Transformation und die Entwicklung eines Softwaremodells, das das Geschäftsproblem als plattformunabhängige Facharchitektur abbildet. Zur Modellierung der Fach- und der abgeleiteten Anwendungsarchitektur wird eine bzgl. ihrer Syntax und Semantik wohldefinierte Modellierungssprache benötigt, die eine Maschinenlesbarkeit der Softwaremodelle ermöglicht. ⁵⁷ Die Maschinenlesbarkeit der Modelle ist eine notwendige Bedingung, um die Transformationen der Modellebenen mit Hilfe von Werkzeugen zu automatisieren. Im Rahmen der MDA wird von der OMG die Modellierungsnotation UML vorgesehen. 58

des Modells in Datenbanktabellen (inkl. Auflösung der Assoziation über Assoziationstabellen),

Quellcode und Konfigurationsdateien (Implementierung mit hohem Detailgrad). Vgl. Roßbach, Peter: Stahl, Thomas, Neuhaus, Wolfgang: Grundlegende Konzepte und 57

Einordnung der Model Driven Architexture (MDA), in JavaMagazin, Ausgabe 09/2003, S. 1,

Online im Internet: http://www.oose.de/downloads/MDA_JavaMagazin_09_03.pdf, Abruf

04.01.2004

Vgl. Miller, Joaquin; Mukerji, Jishnu (Hrsg.): Model Driven Architecture (MDA) Document 58

number ormsc/2001-07-01, Online im Internet, http://www.omg.org/cgi-

Model Driven Architecture 20

Nachdem die mit der MDA verfolgten Ziele erläutert worden sind, folgt eine Einführung der UML unter besonderer Berücksichtigung ihrer Verwendungsmöglichkeiten zur Softwaremodellierung im Rahmen der MDA in Abschnitt 3.5.2, sowie eine detaillierte Darstellung der Basiskonzepte der MDA, der Modellebenen und der Transformationen im Abschnitt 3.5.4 und 3.5.5.

3.3. Ziele

Die OMG verfolgt durch die Trennung der einzelnen Architekturebenen die Ziele der Portabilität, Interoperabilität und Wiederverwendbarkeit von Software. 59

Die Langlebigkeit und Wiederverwendbarkeit von Software soll durch eine stärkere Unabhängigkeit von der Zielplattform der zu entwickelnden Anwendung gewährleistet werden. Die Softwareentwicklung im Rahmen der MDA verlagert den Fokus von der Implementation auf die Planung und Modellierung. Investitionen in die Entwicklung eines umfangreichen, detaillierten Softwaremodells können so Technologiewechsel überdauern. 60

Die Trennung von Softwaredesign und der darunter liegenden Softwarearchitektur kann ebenso die Übertragung der modellierten Geschäftslogik auf alternative oder neue Softwareplattformen erleichtern. 61

Die die Maschinenlesbarkeit ermöglichende strenge Formalisierung der Modelle vereinfacht die Wartung der Softwaresysteme, da die genaue Spezifikation des Systems in dem Modell abgebildet wird. Neben der eigentlichen Erzeugung des Code-Modells aus

bin/apps/doc?ormsc/01-07-01.pdf, Stand 09.07.2001, Abruf: 22.09.2003, S. 9 ff. (im Folgenden

zitiert als MDA)

Vgl. Miller, Joaquin; Mukerji, Jishnu (Hrsg.): MDA Guide, a.a.O., 2.1.2 59

Vgl. Widmann, Thomas: Entwicklung von Geschäftskomponenten unter Berücksichtigung der 60

Model Driven Architecture, Online im Internet:

http://www.sigs.de/publications/os/2003/03/widmann_OS_03_03.pdf, Stand: 03/2003,

Abruf: 09.09.2003, S. 3

Vgl. Strube, Phillip: Einführung in die Model Fiven Architecture (MDA) in Javamagazin 61

05/2002, S. 82

Model Driven Architecture 21

dem plattformspezifischen Modell kann dadurch auch Code zur Integration des Systems, sowie Testfälle und -prozeduren erzeugt werden. 62

Über die aus der Transformation eines PIM in PSM bekannte Verbindung einzelner Elemente der Modellebenen Facharchitektur und Anwendungsarchitektur, können sog. „bridges“ zwischen PSM und Code-Modellen verschiedener Plattformen erzeugt werden (vgl. Abbildung 5). Diese Bridges ermöglichen die Kommunikation, d.h. die Interoperabilität der Software verschiedener Plattformen (ein Transformationsvorgang kann bspw. Code erzeugen, der eine Kommunikation von EJB-Komponenten mit CORBA-Komponenten realisiert. Bridges stellen bspw. auch die Verbindung zwischen Komponenten und der für sie mit Hilfe eines PSM definierten Datenhaltung her). 63

Gleichzeitig steigt die Produktivität der Softwareerzeugung, da fachliche Änderungen, die häufig eine Vielzahl von Änderungen in verschiedenen Bereichen des Softwaresystems nach sich ziehen, durch die Automatisierung des Abbildungsprozesses automatisch auf die technische Plattform abgebildet werden. ⁶⁴ Die automatische Transformation gewährleistet außerdem eine hohe Homogenität der erzeugten Code-Modelle, die überdies je nach Abbildung der Transformationsvorschriften gängigen Best-Practice-Ansätzen genügen können. Die Automatisierung des

Softwareentwicklungsansatzes durch eine MDA-Werkzeugunterstützung reduziert die „time-to-market“ des Softwareentwicklungsprozesses. ⁶⁵ Darüber hinaus können die auf die einzelnen Modellartefakte angewandten Transformationen den Entwicklern die Implementierung von Softwarebestandteilen entsprechend dem der Architektur zugrunde liegenden Regelwerk abnehmen. Entwicklungen der zugrunde liegenden

Vgl. Miller, Joaquin et al., MDA Guide, a.a.O., S 1-2 62

Vgl. Kleppe, Anneke et al.; a.a.O, S. 10 63

Vgl. Ditze, Andreas; Ghadir, Phillip; Tilkov, Stefan: a.a.O., S. 66 64

Vgl. de Miguel, Miguel et al.: Practical Experiences in the Application of MDA in: Jézéquel, Jean- 65

Marc; Hussmann, Heinrich; Cook, Stephen (Hrsg.): «UML» 2002 - The Unified Modeling

Language, Berlin u.a. 2002, S. 129

Model Driven Architecture 22

Softwarearchitektur oder der Implementierungsgepflogenheiten ⁶⁶ können durch Anpassung der Transformationsregeln für bestehende oder neu zu entwickelnde Modelle abgebildet werden. Durch die Möglichkeit der automatischen Code-Generierung aus den entwickelten Modellen kann die Auswahl der zu nutzenden Plattform auf einen späteren Zeitpunkt verlagert und nach Festlegung auf eine Plattform auch wieder geändert werden.

Die MDA soll die Softwareentwicklung als ingenieursmäßige Disziplin etablieren, da ein gewichtiger Anteil der Software nicht mehr manuell erstellt werden muss, sondern automatisch produziert werden kann.

Langfristig soll sogar die direkte Ausführbarkeit von Modellen durch Entwicklung geeigneter Werkzeuge im Sinne eines Modell-Kompilers ermöglicht werden. 67

Bevor die Kernbestandteile der MDA in den folgenden Abschnitten näher erläutert werden, soll durch eine Begriffsbestimmung eine Basis für die weiteren Ausführungen geschaffen werden.

3.4. Begriffsbestimmung

Die OMG verwendet den Begriff der Domäne (engl. Domain), um ein in der Software abzubildendes Problem einem bestimmten Problem- aber auch Personenkreis zuordnen zu können. Die Domäne beschreibt ein Problem in Konzepten auf eine Art und Weise, dass dieses von Anwendern mit Fachwissen in dem Domänenbereich verstanden werden Domänen umfassen Anwendungsbereiche (Online-Kataloge oder kann. ⁶⁸ Betriebswirtschaftliche Anwendungen), Technologie-Domänen (Webtechnlogie,

Datenbanken) oder Programmiersprachendomänen (Java, C++). Die verschiedenen

Die Fokussierung auf möglichst performante Implementierungsansätze bspw. könnte bei 66

Weiterentwicklung der eingesetzten Hardware einen geringeren Stellenwert im Vergleich zu

anderen bis dato vernachlässigten Eigenschaften bekommen.

Vgl. Frankel, David S.: Model Driven Architecture, 1. Auflage, Indianapolis 2003, S. 286 ⁶⁷ 68 Vgl. Nedunuri, Srinivas: Domain Modeling for MDA Using Activity Diagrams, Online im

Internet: http://www.omg.org/news/meetings/workshops/UML2002-Manual/

06-2_Domain_Modeling_for_MDA_Using_UML_Activity_Diagrams.pdf, Abruf 12.12.2003, S. 8

f.