Home

Papers - Business Informatics Group

1. Evaluierung Seite 65 Jede Phase des Entwicklungsprozesses wird durch ein entsprechendes Werkzeug der Nucleus BridgePoint Umgebung unterst tzt Ein Model Repository erm glicht die nahtlose Zusammenarbeit der verschiedenen Tools und dadurch eine integrierte mo dellbasierte Softwareentwicklungsumgebung Abbildung 4 1 zeigt den Aufbau der Nucleus BridgePoint Umgebung Dabei sei noch einmal darauf hingewiesen dass die Model Compiler nicht standardm ig in der Nucleus BridgePoint Umgebung enthalten sind und zus tzlich bezogen werden m ssen was einen erh hten finanziel len Aufwand bedeutet Generator VT Compiler Model Model Builder Verifier Debugger Abbildung 4 1 Aufbau der Nucleus BridgePoint Umgebung nach AT04a Der Model Builder ist fur die erste Phase zust ndig denn mit seiner Hilfe ist die Er stellung von Executable UML Modellen m glich Der Model Verifier ist f r die zweite Phase einzusetzen denn er unterst tzt die Verifikation von Modellen Der Generator nutzt die Transformationspezifikationen der Model Compiler diese Be schreiben die Modell zu Code Transformationsregeln und die im Model Repository gespeicherten Modelle um aus diesen zwei Eingaben den gewunschten Code zu ge nerieren Somit sind fur die dritte Phase der Generator und die Model Compiler die unterstutzenden Komponenten Fur die vierte Phase wird der Model Debugger ein gesetzt um das ubersetzte Modell moglicherweise kombiniert
2. Accelerated Technology Object Action Language Manual mitgeliefert in der Evaluationsversion der Nucleus BridgePointumgebung 6 1 bezie hbar unter http www acceleratedtechnology com 12 1 2005 2004 L Baresi R Heckel Tutorial Introduction to Graph Transformation A Software Engineering Perspective http www elet polim1 it upload baresi papers ICGT pdf 1 2 2005 2002 G DBeneken et al Referenzarchitekturen und MDA http wwwA4 in tum de seifert publications 2004 beneken_mda refarch pdf 15 2 2005 2004 Compuware Corporation Optimal How model driven development enhances productivity http Javacentral compuware com members login click shtml members downloads pdf OJModelDrivenDev pdf 1 2 2005 2004 Compuware Corporation OptimalJ How transformation patterns trans form UML models into high quality DEE applications Literaturverzeichnis Seite 147 CC04c Chri04 Dijk70 http javacentral compuware com members login click shtml members downloads pdf OJPatterns pdf 1 2 2005 2000 Compuware Corporation OptimalJ Architecture Edition OptimalJ 3 3 http javacentral compuware com members optimalj documentation v3 3 UserGuideAE pdf 1 2 2005 2004 A Christoph Describing Horizontal Model Transformations with Graph Rewriting Rules Proceedings of Model Driven Architecture Founda tions and Applications 2005 Seite 76 91 2004 E Dijkstra C Hoare Structured Programming Academic Press
3. Das dynamische Verhalten der Benutzerschnittstelle wird durch Accessor Aktivit tsdiagramme beschrieben Dabei wird jeder Accessor Klasse ein Accessor Kapitel 5 Fallstudie Seite 121 Aktivitatsdiagramm zugewiesen Accessor Aktivitatsdiagramme sind mit proprieta ren Elementen angereicherte UML Aktivit tsdiagramme und verf gen uber Notatio nen f r Zust nde obwohl sie explizit als Aktivitatsdiagramme bezeichnet werden Die zwei wichtigsten Erweiterungskonzepte von Accessor Aktivitatsdiagrammen stellen Representer State und Embedded Accessor State dar e Representer State Ein Representer State ist ein Zustand in dem eine zuge wiesene Representer Klasse angezeigt wird Durch Representer States k n nen auch Ereignisse die in der zugewiesenen Representer Klasse auftreten wie z B die Aktivierung einer Schaltfl che ber cksichtigt werden e Embedded Accessor State Durch Embedded Accessor States wird es einer Accessor Klasse erm glicht weitere Accessor Klassen zu beinhalten bzw zu benutzen Dabei stellt ein Embedded Accessor eine Referenz auf eine Ac cessor Klasse dar Sobald in einem Aktivit tsdiagramm ein Embedded Ac cessor State erreicht ist wird das Aktivitatsdiagramm der referenzierten Ac cessor Klasse ausgef hrt Das Aktivitatsdiagramm der bergeordneten Ac cessor Klasse wird nach dem Beenden des Aktivitatsdiagramms der referen zierten Accessor Klasse fortgesetzt Abbildung 5 8 zeigt das Aktivitatsdiagramm
4. Ein Plattformmodell definiert die technischen Konzepte und Elemente einer be stimmten Plattform Weiters stellt es die Elemente die fur die Modellierung eines plattformspezifischen Systems benotigt werden zur Verfugung Platform Specific Model PSM Ein PSM beschreibt das System das bereits durch CIM und PIM modelliert wurde Der Unterschied liegt darin dass nun plattformspezifische Details ins Modell aufge nommen werden Dadurch enthalt ein PSM Modellierungselemente die fur eine spe zielle Plattform definiert wurden bzw in einem PM Daher ist ein PSM auch nicht mehr plattformunabhangig Um die Modellarten von MDA nochmals zu verdeutlichen und den Einsatz von au tomatisierten Transformationen zu motivieren wird im Folgenden ein konkretes jedoch relativ einfaches Beispiel das in der Abbildung 2 6 dargestellt wird ange f hrt Der Ausgangspunkt ist ein PIM mit zwei Klassen n mlich Benutzer und Ter min Beide Klassen repr sentieren persistente Objekte und sind deshalb mit dem Stereotype entity ausgezeichnet Zus tzlich besitzen beide Klassen jeweils ein eindeutiges Attribut zur Identifikation welche durch di ausgezeichnet sind Es sei darauf hingewiesen dass keine plattformspezifischen Details in diesem Modell ein getragen sind Durch eine Modelltransformation kann aus diesem PIM ein auf J2EE basierendes PSM abgeleitet werden Die beiden Klassen aus dem PIM werden in EJB Entity Beans transformiert und weitere plattform
5. danach wird solange gewartet bis die BenutzerIn durch das Aktivieren der Tick Schaltfl che den n chsten Schritt startet Die Durchf hrung einer Simulation wird in einer Textdatei mit Endung sim_log mitprotokolliert In diesen Dateien werden die Ereignisreihenfolgen das Erzeugen bzw L schen von Objekten und die Zust nde der Objekte festgehalten BridgePoint Model Yerifier Index Window Pale Fa File Help Simulation Workspace Model Workspace System Event Queue microwave sim microwayve ooa MO_It start 000001 From User Created To M _ _000001 Function gt 4 b MAIN 2 0 g Domain microwave Dequeue Eyt Inst amp Start TICK Delete Eyent 1 Clock 0s 000000us Subsystem MAIN 2 0 x Initialization Subsystem af See Near Microwave Oven Start TICK u Stop TICK Test Subsystem d Run Jog Step a C Action Level Ge Statement Level C Component Level 0s O00000us INFO User Created Object Instance MO TI 000C Os 000000us INFO User Created Event Instance MO_1 OO MAIN 2 0 E Showy Copyright c 1992 2001 Project Technology Inc and its licensors All Rights Reserved Abbildung 4 3 Hauptansicht des Model Verifiers 4 2 IUML ICCG Hersteller Kennedy Carter Webseite http kc com Version 1UMLite 2 20 f r Windows Die Firma Kennedy Carter vertreibt die beiden Werkzeuge 1UML und 1CCG 1UML steht f r Intelligent UML und ist f r die Erstellung und S mulation von Exe
6. eingehen zu k nnen Frameworks wie Eclipse und NetBeans sind Referenztechnologien f r Erweite rungsm glichkeiten und Toolintegration doch leider bieten diese Technologien heutzutage noch zu wenig Modellierungsaspekte um MDA zu unterst tzen 13 Unterst tzung von Programmier IDEs MDA Tools sollten die automatische Erstellung von Projektdateien f r die meist verwendeten IDEs w e JBuilder Eclipse und NetBeans als Beispiele m Javabe reich unterst tzen Da bei gro en Projekten eine Vielzahl von Dateien und Ver zeichnissen durch Artefaktgenerierung entsteht hilft dieses Feature der Entwickle rin Zeit zu sparen und sich mehr auf ihre Programmiertatigkeiten zu konzentrieren 3 2 5 konomische Kriterien Diese Kategorie besch ftigt sich mit den wirtschaftlichen Anforderungen an MDA Tools Wie bei jeder Entscheidung ber den Einsatz neuer Technologien sind auch bei MDA Tools Kosten Nutzen Rechnungen angebracht Nat rlich sind die Anschaffungskosten eines Tools eine wichtige Entscheidungs grundlage ob dieses Tool eingesetzt werden soll Doch noch viel kritischer sind die laufenden Kosten die zum Gro teil durch Personalkosten verursacht werden Des halb ist sicherzustellen dass einerseits die EntwicklerInnen das neue Tool akzeptie ren und andererseits rasch lernen damit umzugehen In der Regel wird am Beginn des Einsatzes der neuen Technologien die Produktivitat kurzfristig sinken Erst nach einer gewissen Eina
7. Fallstudie Seite 125 Die persistenten Attribute und Assoziationen einer Entity Bean werden m Allge meinen n relationalen Datenbanken gespeichert Daf r wird em Datenbankschema ben tigt das durch den ArcStyler automatisch und vollst ndig vom EJB Modell abgeleitet werden kann F r jede Entity Bean wird eine eigene Tabelle erstellt Der Name der Entity Bean wird standardm ig als Tabellenname bernommen falls kein anderer Name im MDA Eigenschaftenfenster der Entity Bean spezifiziert wurde F r jedes Attribut bzw jede Rolle wird eine eigene Spalte in der Tabelle angelegt Der Name des Attributes oder der Rolle wird dabei als Spaltenname verwendet Es kann aber ber das MDA Eigenschaftenfenster ein beliebiger Name fur die Spalte verge ben werden Die WLS Cartridge verwendet spezielle Abbildungen fur die Datenty pen Fur eine konkrete Auflistung der Abbildungen zwischen Java Datentypen und SQL Datentypen sei auf O 03d verwiesen Der folgende SQL Code f r das Anle gen und Loschen der Tabellen wird automatisch aus den beiden Entity Beans Termin und Benutzer generiert Skript zum Anlegen der Tabellen CREATE TABLE Eintrag name VARCHAR 300 NOT NULL ort VARCHAR 2000 datum VARCHAR 2000 beginn VARCHAR 2000 dauer VARCHAR 2000 theBenutzer VARCHAR 300 PRIMARY KEY name CREATE TABLE Benutzer benutzername VARCHAR 300 NOT NULL password VARCHAR 2000 PRIMARY KEY benutzername Skript zu
8. GenDfltFactories EmptyParameterList Abbildung 4 12 ArcStylers Auswahlmen f r Markierungen Durch die beschriebene Technik st es m glich Modelle auf verschiedenen Ebenen wie z B PIM oder PSM zu erstellen Durch Markierungen k nnen Entwurfsent scheidungen bezogen auf konkrete Plattformen ber cksichtigt werden um notwen dige Informationen f r die Transformationen in die Modelle einzubringen 4 5 3 MDA Cartridges MDA Engine MDA Cartridges beinhalten Informationen ber Modelltransformationen Modellve r f kationen und ben tigte Profiles Im Allgemeinen repr sentiert eine MDA Cartridge genau eine Plattform und kapselt hre plattformspezifischen Konzepte Um bestimmte Plattformen m ArcStyler zu unterst tzen m ssen die entsprechenden MDA Cartridges importiert werden F r ein Projekt k nnen auch mehrere MDA Cartridges gleichzeitig verwendet werden um die Erstellung von Softwaresystemen die auf mehreren Plattformen basieren zu unterst tzen Tabelle 4 4 g bt einen gro ben berblick ber die in der Standardinstallation enthaltenen MDA Cartridges und ihre Aufgaben Kapitel 4 Evaluierung Seite 91 Bezeichnung Beschreibung MDA Cartridge f r die Erstellung von Java bas erten Systemen MDA Cartridge f r die Erstellung von NET basierten Syste men WebAccessor MDA Cartridge fur JSP oder NET basierte Webanwendungen EJB 1
9. Hersteller von MDA Werkzeugen sollten UML 2 0 so rasch wie m glich in ihre Pro dukte integrieren da UML 2 0 das Potential der modellgetriebenen Softwareent wicklung um einiges steigert Gerade ber den Verhaltensdiagrammen werden in der Version 2 0 deutlich mehr Modellierungsm glichkeiten geboten aber auch be den Strukturdiagrammen wie z B den Komponentendiagrammen werden f r MDA n tzliche Konzepte integriert M2 Erstellung von UML Profiles Um PIMs und PSMs zu erstellen ist es notwendig plattformspezifische Informatio nen seien es abstrakte oder konkrete Plattformen in die Modelle einzuarbeiten Die OMG stellt daf r UML Profiles f r verschiedenste Bereiche und Plattformen zur Verf gung Toolhersteller sollten f r die aktuellsten Plattformen Profiles bereitstel len und es den BenutzerInnen erm glichen eigene Profiles zu erstellen bzw die be reitgestellten Profiles zu modifizieren Dabei sollten Profiles aus Stereotypen Schl sselwort Wert Paaren und Einschr nkungen bestehen Zus tzlich sollte ein integrierter Profile Editor angeboten werden der die Bearbeitung bzw Erstellung von Profiles erleichtert M3 Definition von auf MOF basierenden Metamodellen UML Profiles sind eine m gliche Erweiterungsform des UML Metamodells Oft reicht aber eine Erweiterung nicht aus und es ist die Modellierung eines neuen Me tamodells notwendig Um der Forderung der OMG MOF als Metametamodell e rungssprache zu benutzen nachzugehe
10. Werkzeuge wird eine erste Entscheidungshilfe geboten um zu bestimmen welche Werkzeuge f r den Einsatz in einem bestimmten Projekt in Frage kommen Weiters erleichtert ein verbessertes Verst ndnis ber MDA die Auswahl eines ge eigneten MDA Werkzeuges Werkzeuge die die speziellen Anforderungen eines Projektes unterst tzen optimieren bzw automatisieren h ufig auftretende Arbeits schritte und entlasten dadurch ProgrammierInnen von Routinetatigkeiten Durch die Sensibilisierung der Anwender hinsichtlich der signifikanten Unterschiede im Funk tionsumfang der MDA Werkzeuge wird auch die langfristige Entwicklung von MDA gesichert da keine unerf llbaren Erwartungen bei den AnwendernInnen ge weckt werden Kapitel l Einleitung Seite 13 1 3 Zielsetzung Diese Diplomarbeit soll die theoretischen Grundlagen der MDA und ihre praktische Umsetzung durch konkrete Technologien erkl ren Der Leser soll durch diese Arbeit Antworten auf folgende Fragen bekommen e Was sind Modelle und wie k nnen diese effizient zur Codegenerierung ge nutzt werden e Welche verschiedenen Modellarten k nnen im MDA Paradigma unterschie den werden und wie werden diese in weitere Modellarten transformiert e Welche Technologien bzw Standards sollen in einem MDA Projekt einge setzt werden e Welche Anforderungen sollten MDA Werkzeuge erf llen e Welche MDA Werkzeuge haben sich am Softwaremarkt etabliert e Wie unterscheidet sich ein MDA Sof
11. n der Java Server Page ber cksichtigt Class Specification General Attributes Operations Template Parameters Inner Elements Relations Stereotypes Tagged Values Constraints Arcstyler Extension MDA Marks E R AnmeldenRep representer ArcStyler WebAccessors SS La root panel Eli representer custom properties ModelGenerator vip benutzername text field a password text field cn RenresenterRoot LBE message static field Abbildung 5 10 Benutzerschnittstellenelemente der Klasse AnmeldeView Die folgenden zwei Codefragmente werden automatisch aus der Representer Klasse AnmeldenView erzeugt Die Benutzerschnittstellenelemente der Klasse Anmelde View werden in Abbildung 5 10 aufgelistet Das erste Codefragment reprasentiert einen Auszug aus der AnmeldeView Java Klasse Die Benutzerschnittstellenelemen te der Representer Klasse werden als innere Klassen implementiert wobei die innere Klasse f r das Panel root alle weiteren inneren Klassen f r die Elemente beinhaltet package webAccessors anmelden public class AnmeldeView extends com io_software catools 7J spacc bob JspActionContainer public AnmeldeView java lang String benutzername java lang String password java lang String message public class _ce_Root extends ASPanelModel public class _ce Benutzername extends ASTextFieldModel Kapitel 5 Fallstudie Seite 128 public _ce_Benutzername String p_ElementName super p_ElementName
12. Code der direkt aus dem Applikationsmodell erzeugt wird Dabei werden nicht nur Java Klassen generiert sondern auch alle f r den Applikations Datenbankserver ben tigten XML SQL Dateien Die automatisch generier te Applikation ist sofort ohne Modifikationen in der OptimalJ Umgebung ausf hrbar und dadurch testbar Der Code wird auf Basis von Design Pat terns nach Gamm96 erstellt um den Code leicht verst ndlich und gut wart bar zu halten Die beiden letztgenannten Eigenschaften sind u erst wichtig da im Code Funktionen von den EntwicklerInnen implementiert werden m ssen die im Dom nen bzw Applikations Modell nicht spezifiziert wer den k nnen Um diese manuellen nderungen am Code vornehmen zu k n nen ist der automatisch erzeugte Code n frei editierbare und f r den Gene rator gesch tzte Bereiche nicht zu verwechseln mit den f r Programmiere rInnen gesch tzten Bereichen im Kriterienkatalog unterteilt F r den Gene rator gesch tzte Bereiche sind im Netbeans basierten internen Editor blau hinterlegt Abbildung 4 6 und k nnen durch die BenutzerIn nicht ver ndert werden Hingegen k nnen frei editierbare Bereiche von der BenutzerIn mo difiziert werden und sind im internen Editor wei hinterlegt Abbildung 4 6 Zusatzlich zum internen Editor wird fur den Code eine Exportfunktion in Projektdateien fur die bekanntesten Programmier IDEs wie Borland JBuilder oder SUN ONE Studio angeboten Fur den Code der Prasentationssc
13. Dieser k nnte durch weitere Kriterien f r Reverse Engineering erg nzt werden e Bei der Fallstudie wurde auf bereits vorhandene Transformationsdefinitio nen zur ckgegriffen Hier w re noch zu kl ren mit welchem Aufwand die Erstellung eigener Transformationen verbunden ist Da die evaluierten MDA Werkzeuge unterschiedliche Transformationsdefinitionsmoglichkeiten anbieten w re es interessant die Vor und Nachteile der einzelnen Ans tze herauszuarbeiten e Weiters wurde nur eine relativ kleine Webapplikation fur die Fallstudie imp lementiert Dabei ware aber noch zu klaren wie sich zusatzliche Aspekte wie Mehrbenutzerzugriff Austausch der Modelle zwischen unterschiedli chen Werkzeugen und die Modellierung von Verbindungen Brucken zwischen eigenst ndigen Anwendungen bei der Erstellung einer gro en und Kapitel 6 Zusammenfassung und Ausblick Seite 140 komplexen Anwendung die mehrere EntwicklerInnen miteinschlie t aus wirken Zus tzlich k nnten Fallstudien f r unterschiedliche Applikationsarten und architekturen z B Web Services durchgef hrt werden um zu eruieren welche Projekte vom Einsatz des MDA Paradigmas profitieren und welche nicht Anhang A Modell der Terminverwaltung A 1 Arcstyler Projektdatei siehe CDROM Kalendar asprj A 2 Modell als XMI Datei XMI Version 1 1 siehe CDROM Kalendar xml A 3 automatisch generierte Dokumentation der Terminverwaltung siehe CDROM dokumentation index h
14. automatische Generierung der Datenbankschemata aus dem Modell des EJB Subsystems genauer eingegangen EJBs werden in einem EJB Klassendiagramm als Klassen modelliert und mit dem Stereotyp ComponentSegment gekennzeichnet In einem ComponentSegment wer den alle EJB Eigenschaften f r Home Schnittstelle Remote Schnittstelle Imple mentierungsklasse und optionale Prim rschl sselklasse n einer UML Klasse gekap selt Die Abbildung 5 5 zeigt das EJB Klassendiagramm f r die beiden Entity Beans Benutzer und Termin lt Gomponentsegment Benutzer Arcswler ArcstwlerEJB 11 GenDiltfactories sEmpWParameterLlist Arcstwler ArcStwlerEJB 11 PersistenceManagementContainer henutername StringfArcStwler ArcStylerEJB 11 Par ffrimankey ArcStylerPWL561_CMPisUnigue nassword String 1 theBenutzer hatlermine E theEintraege lt lt Componentsegment gt gt Termin ArcStyler ArcStylerEJB 11 PersistenceManagementeGontainer heginn String cdlatum String rauer String tname StringfArcStpler Arce tylerEJB 11 PartOtPrimarnkey ArcStylerSVVWLS61_CMP isUnique tot String eacreates createl name String datum String beginn String dauer String ort String Abbildung 5 5 Auszug aus dem EJB Klassendiagramm der Terminverwaltung Kapitel 5 Fallstudie Seite 119 Die Eigenschaften einer Bean wie z B der Typ der Bean Entity Session oder Mes sage driven mussen durch Markierungen 1m Mode
15. gangenheit wurden bereits verschiedene Abstraktionsebenen in den Programmier sprachen eingefuhrt Am Anfang der Geschichte der Softwareentwicklung wurden Programme als Maschinencode Folge von Nullen und Einsen geschrieben und wel ters auch in dieser Form gespeichert Da noch viele Details der verwendeten Hard ware 1m Code ber cksichtigt wurden war ein Programm nur auf der daf r vorgese Kapitel 1 Einleitung Seite 4 henen Maschine lauff hig Die erste Abstraktion von Maschineninstruktionen war die Einf hrung von Assemblersprachen Damit war es m glich Programme f r eine bestimmte Hardwareplattform als Sammlung von Mnemonics zu entwickeln Mit der Einf hrung von Hochsprachen wie z B Fortran und C wurde die n chste Abstrakti onsstufe erreicht Vorerst herrschte Ablehnung gegen diese Hochsprachen da man die Meinung vertrat dass der durch Compiler bersetzte Programmcode zu hohe Performanceverluste einbrachte Doch mit der Entstehung ausgereifter Entwick lungswerkzeuge und Compiler konnten die Gegner bekehrt werden und bald erkann te man dass nur f r wenige spezielle Applikationen h ndisch programmierter As semblercode notwendig war E n Gro teil des Erfolges von Hochsprachen begr ndet s ch auf folgenden Errungenschaften e Standards f r C erm glichen die Portabilitat von Programmen zwischen ver schieden Hardwareplattformen e Mit der Strukturierung des Programmcodes n Funktionen oder Subroutinen ist es m gl
16. ngig vom Typ der Zust nde F r je den Zustandstyp gibt es eine quivalente Java Klasse die besondere Funktionalit t f r diesen Zustandstyp bietet Die Klasse vertex Anmeldung erbt zum Beispiel von der Klasse com io_software catools jspacc accessor fsm RepresenterState da der Zustand Anmeldung von Typ RepresenterState ist Die inneren Klassen sind mit speziellen Methoden die sie von ihren Elternklassen erben ausgestattet package webAccessors anmelden public class CalendarAccessor extends com io_software catools jspacc accessor AccessorGenBaselImpl public CalendarAccessor java lang String benutzername java lang String password java lang String message ejbCalendarium Kalendar kalendar public class _vertex_top extends com io_software catools picasso fsmrt TopState public class _vertex_start extends com io_software catools picasso fsmrt InitialState public class _vertex_Anmeldung extends com io_software catools jspacc accessor fsm RepresenterState public class _vertex_check extends com io_software catools picasso fsmrt State Kapitel 5 Fallstudie Seite 127 Eine Representer Klasse wird n eine Java Klasse mit dem Namen der Representer Klasse und n eine Java Server Page mt dem Namen der Representer Klasse trans formiert Die Benutzerschnittstellenelemente einer Representer Klasse werden als innere Klassen in der Java Klasse und als Methodenaufrufe f r die Erzeugung der Elemente
17. rung von Softwareartefakten aus Modellen basierend auf der Model Driven Archi tecture erm glicht Entwickelt und vertrieben wird das Produkt von der deutschen Firma Interactive Objects Software GmbH die bereits im Jahr 1990 als Consulting Unternehmen gegr ndet wurde Das Hauptgesch ftsumfeld der Unternehmung war die Erstellung von Architektur Entwurf und Implementierung von Objekt und Komponentenorientierten Softwaresystemen Daraus entwickelte sich ihr neues Hauptbesch ftigungsfeld n mlich die Entwicklung eines MDA Werkzeuges Entwickelt wurde dieses in Java um nicht auf ein bestimmtes Betriebssystem be schrankt zu sein Erkauft wird diese Unabhangigkeit durch hohe Anforderungen an die Hardware Als minimale Konfiguration werden 1 4 GHz Prozessorleistung und 256 MB Arbeitsspeicher genannt Doch die Praxis zeigte dass unter diesen Vorraus setzungen ein sinnvolles Entwickeln nur bedingt durchf hrbar ist Deshalb sollte man zumindest die empfohlene Konfiguration von 2 GHz Prozessorleistung und GB Arbeitsspeicher erf llen Die zweite Generation des ArcStylers fokussiert auf den gesamten Lebenszyklus eines Softwaresystems von Analyse Entwurf Entwicklung bis hin zur Verteilung und Tests Versionen der ersten Generation Version lt 4 0 waren noch nicht mit einem integrierten Modellierungswerkzeug ausgestattet Stattdessen wurde der Ein satz des Modellierungswerkzeugs Rational Rose von IBM empfohlen Ab Version 4 0 wurde das UML Mo
18. 1972 Gamm96 E Gamma R Helm R Johnson Design Patterns Addison Wesley Ver Gard03 Heck00 T003a T003b T003c lag 1996 T Gardner et al A review of OMG MOF 2 0 Query Views Transformations Submissions and Recommendations towards the final Standard http www zurich ibm com pdf ebizz gardner etal pdf 1 2 2005 2003 R Heckel G Engels Graph Transformation and Visual Modeling Tech niques http wwwes upb de cs ag engels Papers 2000 HeckelEATCS00 pdf 12 2 2005 2000 Interactive Objects Software GmbH ArcStyler Platform Guide for Arc Styler Version 4 0 http www arcstyler de as_support docu ArcStyler Platform Guide pdf 12 2 2005 2003 Interactive Objects Software GmbH ArcStyler MDA Cartridge Devel opment and Extensibility Guide for ArcStyler Version 4 0 http www arcstyler de as_support docu extensibility guide pdf 12 2 2005 2003 Interactive Objects Software GmbH ArcStyler 4 0 Product Background Information http www arcstyler de as_support brochures ArcStyler4 Product Backgrounder E pdf 12 2 2005 2003 Literaturverzeichnis Seite 148 T003d ITU03 JCP02 Kapp03 KC01 KC02a KC02b KC04 Klep03 Lang03 Interactive Objects Software GmbH ArcStyler MDA Cartridge Guide for BEA Weblogic Server 8 1 for ArcStyler Version 4 0 http www arcstyler de as_support docu WLS Guide pdf 12 2 2005 2003 International Telecommunication Union
19. 4 15 interner Editor des Objecteering UML Modeler Tools 97 Abbildung 4 16 Hauptansicht des Objecteering UML Profile Builders 100 Abbildung 4 17 Auszug aus dem Objecteering UML Metamodell 0 102 Abbildung 5 1 funktionale Anforderungen an die Terminverwaltung 111 Abbildung 5 2 Entitaten der Terminverwaltung ccccccceeeseeeseeseeeeseeeeeeeeeeeees 112 Abbildung 5 3 Architektur des Termnverwaltungsswstemg 114 Abbildung 5 4 Konfiguration der MDA Cartridges nn 117 Abbildung 5 5 Auszug aus dem EJB Klassendiagramm der Terminverwaltung 118 Abbildung 5 6 Markierungsfenster eines Componentaegments 119 Abbildung 5 7 Accessor Diagramm f r die Anmeldung eines Benutzers 120 Abbildung 5 8 Akt vit tsdiagramm f r die Accessor Klasse Hauptseite 122 Abbildung 5 9 Komponenten der Terminverwaltung cccccccccecceeeeeeeeeeeeeees 123 Abbildung 5 10 Benutzerschnittstellenelemente der Klasse AnmeldeView 127 Abbildung 5 11 ANT Fenster des ArcStylers uuu000csassnennnasanenneseeennennen 133 Tabellenverzeichnis Tabelle 3 1 Tabelle 3 2 Tabelle 3 3 Tabelle 3 4 Tabelle 4 1 Tabelle 4 2 Tabelle 4 3 Tabelle 4 4 Tabelle 4 5 Tabelle 4 6 Tabelle 4 7 Tabelle 4 8 Tabelle 4 9 Executable UML Konzepte nach MellO2 58 Executable UML TOONS unse gege 58 plattfor
20. Abbildung 5 9 Komponenten der Terminverwaltung 5 3 2 Generierung der Artefakte Dieses Unterkapitel beschaftigt sich mit der Codegenerierung In diesem Schritt der Softwareentwicklung werden der Codegenerator und die MDA Cartridges aktiviert um die notwendigen Artefakte f r ein lauff higes Softwaresystem aus UML Modellen zu erstellen Die Erklarung der automatischen Codegenerierung wird fur die beiden Subsysteme EJB Subsystem und Web Subsystem getrennt durchgef hrt Dabei wird f r beide Subsysteme folgende Vorgehensweise f r den Transformati onsprozess angewendet Konfiguration des Codegenerators Modellverifikation und Aktivierung der Transformation Transformation des EJB Subsystems Bevor der Codegenerierungsprozess gestartet werden kann muss der Codegenerator konfiguriert werden Im Besonderen m ssen folgende Einstellungen ber das MDA Konfigurationsmen vorgenommen werden e Ausgabepfad der zu generierenden Artefakte e Konfiguration des Datenbankservers e Konfiguration des Applikationsservers Um sicherzustellen dass nur fehlerfreie Modelle transformiert werden ist die ber pr fung der Struktur des Modells notwendig ArcStyler bietet durch seine WLS Cartridge eine eigene Verify Funktion f r EJB Modelle Bei der Ausf hrung der Modellverifikation werden Warnungen Fehlermeldungen f r nicht optima le fehlerhafte Modellierungen ausgegeben Kapitel 5 Fallstudie Seite 124 Der Transformationsprozess wird mit d
21. Add ie Log Length ER Transformations WebAccessors WebAccessors Remove ef Generate Reload Cartridges Refresh Sox Executable MDZ a VP Modeling Tool CIX JBuilder Logging Eclipse Build Database Admin Server Config Tool Locations m Accessor Prope Generator Profiling XMI Model Client Config FSM Support RMI OCL Webserices Test Server Config B E Harvester i Lang Global Output directory for generated artifacts Po 8 Za Cartridge IDE kp EC Options Cartridge components working directory Coloring Cartridge source code directory fwis8_gen Key Assi i a Key Assignment Gepet Artifact Encoding e g SES Default operation body Return default value v Default Ant options Get DTDs from ArcStyler rt v DEE Version Oe v Project configuration D magister Kalendar asprj Domain configuration C VAreStyler configuration as4md arcstyler cfg User imsi Cancel Abbildung 5 4 Konfiguration der MDA Cartridges Im Folgenden wird zuerst auf die Modellierung des logischen EJB Subsystems ein gegangen und danach die Modellierung des logischen Web Subsystems erl utert Sobald die beiden logischen Subsysteme modelliert sind werden die physischen Komponenten der Anwendung modelliert Erstellung des logischen EJB Subsystemmodells In diesem Abschnitt wird auf die Modellierung der Gesch ftslogik und der Datenhal tung eingegangen Um die Modellierung de
22. Fokus der Fallstudie nicht auf der Erstel lung eines komplexen Systems liegt sondern es soll je ein Beispiel f r die Imple mentierung eines Konzeptes wie z B Datenbankkommunikation Benutzerschnitt stelle und Gesch ftslogik geboten werden Durch die Fallstudie wird gezeigt wel che T tigkeiten in einem MDA Entwicklungsprozess f r die EntwicklerInnen anfal len und welche durch Werkzeugeinsatz effizient und automatisiert durchgef hrt werden k nnen Weiters sollen Vorteile und auch m gliche Nachteile eines modell getriebenen Entwicklungsansatzes aufgezeigt werden Im Zuge der Erstellung der Anwendung soll auch der derzeitige Stand der MDA Werkzeuge durch den Einsatz des ArcStyler Werkzeuges beispielhaft aufgezeigt werden Dieses Kapitel ist in vier Hauptbereiche eingeteilt Unterkapitel 5 1 beschreibt die Anforderungen an das f r die Fallstudie zu erstellende System Der Abschnitt 5 2 gibt eine kurze Einf hrung in die einzusetzenden Technologien Die Durchf hrung der konkreten Entwicklung des Systems wird im Abschnitt 5 3 beschrieben Ab schlieBend werden die Erfahrungen aus der Fallstudie 1m Unterkapitel 5 4 zusam mengefasst Das vollstandige Modell der Terminverwaltung befindet sich in Anhang A und der Code der Implementierung befindet sich in Anhang B Kapitel 5 Fallstudie Seite 111 5 1 Beschreibung der Terminverwaltung Als Fallstudie wird eine Terminverwaltung als Webapplikation implementiert Die Terminverwaltung ist ei
23. Formulierung der nicht automatisch erzeugbaren Gesch ftslogik auf Code ebene verwendet werden Kapitel 3 MDA Werkzeuge Seite 51 Ein weiterer interessanter und in Zukunft immer wichtiger werdender Aspekt ist die Integration und Nutzung von Open Source IDE Plattformen wie Eclipse und Net Beans NetBeans verf gt bereits ber ein auf MOF basierendes Repository namens Meta Data Repository MDR F r Eclipse werden erweiterbare Plugins f r Model lierung wie das Eclipse Modeling Framework angeboten Es ist bereits absehbar dass in Zukunft laufend neue MDA Aspekte zu diesen Plattformen hinzugefugt wer den Im Folgenden werden die Anforderungen der Kategorie Toolinteroperabilitat und Toolintegration aufgelistet und beschrieben I1 Unterst tzung von XMI Um die Unabhangigkeit der Modelle von Tools zu bewahren und nicht in Zukunft in einer speziellen Technologie gefangen zu sein muss eine M glichkeit geboten wer den um die erstellten Modelle f r andere Tools nutzbar zu machen MDA Tools bieten unterschiedliche Funktionalit ten Daher ist eine Kette von Tools durchaus s nnvoll um die erfolgreiche und effiziente Entwicklung eines Softwaresystems zu gew hrleisten Zumindest der Import und Export von Modellen ber das XMI Format sollte em MDA Tool anbieten um die Modelle mit anderen Tools zu teilen Ein auf MOF ba sierender XMI Austausch ware noch vorteilhafter da er den Export von Modellen als MOF Instanzen anstatt Instanz
24. ITU T Recommendation Z 142 Testing and Test Control Notation version 3 TICN 3 Graphical pres entation format http www itu int 1tudoc itu t aap sg 17aap history z142 12 2 2005 2003 Java Community Process JSR 000040 Java Metadata Interface API Specification 1 0 Final Release http jcp org aboutJava communityprocess final jsr040 index html 1 2 2005 2002 G Kappel M Hitz UML Work Von der Analyse zur Realisierung 2 Auflage dpunkt verlag 2003 Kennedy Carter UML ASL Reference Guide ASL Language Level 2 5 http www kc com cgi bin download cgi action ctn CTN 06v2_ 5c pdf 15 2 2005 2001 Kennedy Carter Supporting Model Driven Architecture with eXecutable UML http www kc com cgi bin download cg1 action ctn CTN_80v2_2 pdf 15 2 2005 2002 Kennedy Carter Configurable Code Generation in MDA with ICCG http www kc com cgi bin download cgi action ctn CTN_27v3_0 pdf 15 2 2005 2002 Kennedy Carter Model Driven Architecture and eXecutable UML http www vmasc odu edu wscc pres kennedy ppt 2 3 2005 2004 A Kleppe J Warmer W Bast MDA Explained The Model Driven Architecture Practice and Promise Addison Wesley Verlag 2003 B Langlois N Farcet THALES recommendations for the final OMG standard on Query Views Transformations http www softmetaware com oopsla2003 langlois pdf 1 2 2005 2003 Literaturverzeichnis Seite 149 Mars03 F Marschall P Braun Model Transformations for the MDA wit
25. Seite 139 sprengen w rde Im Folgenden werden die wichtigsten offenen Problemstellungen und weiterf hrenden Aufgabenstellungen aufgelistet die in dieser Arbeit nicht n her behandelt werden und als Startpunkt f r weitere Arbeiten dienen k nnen e Ein offener Punkt der Arbeit ist die Fragestellung mit wie viel Aufwand e1 ne auf NET basierende Applikation aus dem vorhandenen Modell der Ter minverwaltung abzuleiten w re ArcStyler bietet eine NET Cartridge die auf demselben Komponentenmetamodell wie die WLS Cartridge aufbaut Somit w re zu kl ren ob auf Modellebene nderungen vorgenommen wer den m ssen und welche Arbeiten auf Codeebene notwendig s nd Diese Aufgabenstellung ist ein gutes Beispiel um festzustellen mit welchem Auf wand die Nutzung neuer Plattformen f r vorhandene Systeme verbunden w re e In dieser Arbeit wurde ausschlie lich die Generierung von Anwendungen aus Modellen betrachtet jedoch stellt der umgekehrte Weg d h die Generie rung von Modellen aus vorhandenen Systemen Reverse Engineering eine weitere gro e Herausforderung dar Die aus den vorhandenen Systemen er stellten Modelle k nnen f r d e Erstellung neuer Anwendungen welche auf anderen Plattformen bas eren genutzt werden Hier w re zu pr fen ob und wie umfangreich Funktionen f r Reverse Engineering in MDA Werkzeugen implementiert sind Der Kriterienkatalog beinhaltet nur Kriterien fur die Erstellung von Anwen dungen aus Modellen
26. XP und Solaris angeboten Fur die Evaluierung wird die Version 6 1 Windows Edition eingesetzt Diese Version ist kostenlos uber die Homepage der Accelerated Technology Abteilung beziehbar und eine f r ein Monat g ltige Serien nummer wird von einem Betreuer der Firma Mentor Graphics per e mail zugesandt Leider sind in dieser Version keine Model Compiler enthalten Diese sind gesondert von der Firma Mentor Graphics zu beziehen und werden nicht kostenlos zur Verf gung gestellt Daher wird in dieser Arbeit auf Model Compiler nur beschr nkt einge gangen In Nucleus BridgePoint wird die Entwicklung von Softwaresystemen in vier Phasen eingeteilt In der ersten Phase wird ein PIM mit Hilfe der Executable UML Notation erstellt Phase Zwei beinhaltet die Verifikation und den Test des in Phase Eins er stellten Modells auf Modellebene d h das Modell braucht dazu nicht in Code trans formiert werden Die dritte Phase stellt die Transformation des Modells n eine kon krete Implementierung wie C oder C dar In der vierten Phase ist es m glich das transformierte Modell zu debuggen jedoch nicht auf den Elementen der Codeebene basierend sondern auf den Elementen der Modellebene Ist die EntwicklerIn mit der Qualit t und der Funktionalit t des erstellten Systems zufrieden werden die automa tisch generierten Quelltexte kompiliert und in eine ausf hrbare Datei wie in einem herk mmlichen Softwareentwicklungsprozess transform ert Kapitel 4
27. auto matisiert durchgef hrt werden da durch Automatisierung eine enorme Produktivi t tssteigerung erreicht wird Um die Investitionen in Transformationendefinitionen zu sch tzen bedarf es einer standardisierten Transformationssprache Die OMG er kannte diese Notwendigkeit und leitete die Standardisierung einer MOF basierenden Query View Transformation Sprache ein Leider konnte bis heute noch kein Stan dard durchgesetzt werden da s ch f nf der acht eingereichten Vorschl gen noch m Rennen um die Standardisierung befinden Die Anforderungen an eine Que ry View Transformation Sprache und die Realisierung dieser Anforderungen in den eingereichten Vorschl gen werden in Gard03 und Lang03 besprochen Kapitel 3 MDA Werkzeuge In diesem Kapitel wird auf Werkzeuge welche eine sinnvolle Verwendung in einem MDA Projekt finden k nnen n her eingegangen Da die Vorteile des modellgetrie benen Software Engineerings erst mit dem Einsatz von Werkzeugen realisiert wer den ist es eine Notwendigkeit die passenden Werkzeuge f r einen konkreten An wendungsfall zu finden Am Softwaremarkt werden zahlreiche MDA kompatible Tools angeboten aber nur ein kleiner Teil der Produkte wird seinen Anspr chen der Erf llung des MDA Paradigmas gerecht Da MDA heutzutage einen lukrativen Mar ketingfaktor darstellt werden leider auch einige ltere Tools wie plattformspezifi sche Skeleton Codegeneratoren und CASE Tools unter dem Namen MDA neu ver
28. berblick ber den Aufbau des OMG Ansatzes Im Folgenden werden die vier Ebenen der Metamodellierung anhand von MOF und UML genauer beschrieben MO Ebene Instanzen Elemente der MO Ebene repr sentieren reale Entitaten oder ihre entsprechenden Ab bildungen in der Software Als Beispiel konnte ein Arzttermin am 1 1 2004 um 13 Kapitel 2 Model Driven Architecture Seite 25 Uhr fungieren Die Eigenschaften von Terminen werden eine Ebene h her d h auf der M1 Ebene modelliert M1 Ebene Modell des zu beschreibenden Systems Auf dieser Ebene befinden sich Modelle von Softwaresystemen welche z B in UML oder CWM modelliert werden Die Konzepte auf der M1 Ebene stellen Kategorisie rungen von Instanzen der MO Ebene dar Ein Element der MO Ebene wird durch ein Element der M1 Ebene repr sentiert Diese Beziehung wird in der Abbildung 2 5 mit dem Stereotyp representedBy notiert M2 Ebene Metamodell Die Elemente der M1 Ebene sind Instanzen von Elementen der M2 Ebene Diese Beziehungen wird in der Abbildung 2 5 mit dem Stereotyp instanceOf notiert M2 Elemente kategorisieren MI Elemente Die Unterteilung n Ebenen hilft die Aufgaben der Elemente zu trennen Auf MI m ssen nur d e Konzepte definiert wer den welche f r Instanzen der MO Ebene relevant sind Ebene M2 beinhaltet wieder um nur Konzepte z B Class und Association die auf M1 verwendet werden Die M2 Ebene wird auch Metamodellebene genannt da auf dieser Ebene die
29. cksich tigen sind sogenannte Bridges Br cken zwischen Dom nen definierbar Mit Hilfe der Br cken s nd Informationen zwischen Dom nen ber genau spezifizierte Verbindungspunkte austauschbar Die verschiedenen Dom nen Kapitel 3 MDA Werkzeuge Seite 57 und hre Abh ngigkeiten k nnen durch Pakete und Paketabh ngigkeiten vi sualisiert werden e Zustandsdiagramm Jede im Klassendiagramm spezifizierte Entitat besitzt einen Lebenszyklus der durch em Zustandsdiagramm beschrieben wird Somit besitzt jede Klasse em Zustandsdiagramm um seine tempor ren Zu stands nderungen und sein Verhalten zu beschreiben Ein Zustandsdia gramm formalisiert den Lebenszyklus eines Objektes anhand von Zust nden Ereignissen und Transitionen Ein Zustandsdiagramm kann alternativ als Zu stands Transitions Tabelle visualisiert werden In einer solchen Tabelle be schreibt jede Zeile einen Zustand und jede Spalte ein Ereignis Zustandsdiagramme synchronisieren hr Verhalten untereinander durch das Senden von S gnalen die von empfangenden Zustandsdiagrammen als Er eignis interpretiert werden Ein Signal wird als asynchrone Nachricht die Daten transportiert betrachtet Durch den Empfang eines Signals feuert eine Transition im Zustandsautomaten wobei eine Prozedur ausgef hrt wird Diese Prozedur muss bis zu ihrem Ende durchlaufen werden erst danach kann ein neues Signal verarbeitet werden e Aktion Das Verhalten von Systemen ist durch d
30. der bei den Beantypen liegt darin dass Message driven Beans nur durch das Senden von Nachrichten uber das Java Message Service JMS aufgerufen werden Ein Client kann nicht wie bei Session Beans blich ber eine Schnittstelle auf eine Message driven Bean zugreifen sondern muss JMS als API fur das Senden der Nachrichten verwenden Message driven Beans erlauben J2EE Applikationen asynchron zu kommunizieren Kapitel 5 Fallstudie Seite 114 Ein Client einer EJB kann vielartig sein wie z B ein Servlet ein Applet oder eine andere EJB Dadurch kann eine komplexe Aufgabe auf mehrere Beans aufgeteilt werden und somit ist es m glich die Aufgabe in mehrere kleinere Teilaufgaben zu zerlegen Architektur der Terminverwaltung Abbildung 5 3 gibt einen berblick ber die Architektur der Terminverwaltung Die Applikation wird in drei Schichten eingeteilt Pr sentations Gesch ftslogik und Datenhaltungsschicht Ein Client fordert seine Seiten ber einen Controller an Der Controller entscheidet ob er sofort eine Antwort in Form einer Webseite zur cksen det oder vorher selbst eine Anfrage an den Applikationsserver stellen muss Im Ap plikationsserver laufen die Geschaftslogikkomponenten ab Diese kommunizieren mit einem Datenbankserver um persistente Daten abzufragen zu speichern oder zu ndern Somit st die durch das MVC Muster geforderte Trennung erreicht Die JSPs bzw Servlets f r die View bzw Controllerschicht befinden sich in
31. einem Webser ver Die Gesch ftslogik befindet sich als Session Beans gekapselt in einem Applika tionsserver Die Entity Beans fur die persistenten Daten befinden sich auch im Ap plikationsserver und kommunizieren zus tzlich mit dem Datenbankserver in dem die eigentliche persistente Speicherung vorgenommen wird Prasentation Geschiftslo Datenhaltung response Daten Entity Beans Aktivitaten Session Beans Abbildung 5 3 Architektur des Terminverwaltungssystems Kapitel 5 Fallstudie Seite 115 Technologiewahl F r die Fallstudie werden folgende Technologien eingesetzt BEA Weblogic Server in der Version 8 1 als DEE Applikationsserver Jakarta Tomcat in der Version 4 0 1 als Webserver und PointBase als Datenbankserver PointBase wird deshalb als rela tionale Datenbank verwendet da diese mit dem BEA Weblogic Server kostenlos mitgeliefert wird MDA Werkzeugwahl Fur die Erstellung der Webapplikation wird das MDA Werkzeug ArcStyler einge setzt da ArcStyler gerade fur J2EE Anwendungen standardm ig gute Unterstut zung bietet ArcStyler unterst tzt das MVC Muster und verf gt ber ausgereifte Transformationen f r die Generierung von J2EE Anwendungen aus UML Modellen Ein gro er Vorteil des ArcStyler Werkzeuges ist die integrierte Testumgebung die uber spezielle Menus fur Applikations Datenbank und Webserver konfiguriert werden kann Durch die integrierte Testumgebung konnen Prototypen rasch entwi ckelt un
32. f r die Verhaltensmodellierung Aktivitatsdiagramme Die erstellten Domanenmodel le werden n Repositories gespeichert und k nnen als Schablonen in den Modellie rungswerkzeugen verwendet werden In Arlo04 werden bereits einige Dom nen durch sogenannte Archetype Patterns spezifiziert und die OMG arbeitet intensiv an der Erstellung von Dom nenspezifikationen Das Ziel der OMG ist die automati sierte Erstellung von PSMs aus den definierten Dom nenmodellen Abbildung 1 5 gibt zusammenfassend einen berblick ber die besprochenen Kon Dom nen modelle zepte und ihre Wiederverwendungspotentiale Objekte Wiederverwendungspotential Abbildung 1 5 Wiederverwendungspotential von Software Business to Code Mappings werden nicht archiviert Bei der Erstellung einer Applikation wird berlegt wie der Problemraum in Pro grammcode L sungsraum abgebildet werden kann Diese berlegungen werden aber nicht separat gespeichert sondern gehen nach dem Erstellen des Codes wieder verloren bzw werden mit den plattformspezifischen Details 1m Code verflochten l http www omg org technology documents domain spec _catalog htm Stand 12 2 2005 Kapitel 1 Einleitung Seite 11 Danach ist der Problemraum zwar implizit 1m Programmcode enthalten aber um diesen rekonstruieren zu k nnen bedarf es eines muhsamen Re Engineerings Auch hierf r bietet die MDA einen Losungsweg an Die Applikation in einem PIM zu modellieren s
33. ferenzen auf Metaklassen oder Stereotypen m Meta Explorer angef gt In Instanzen von Notes Typen wird der gew nschte Text der weiters f r die Artefaktgenerierung genutzt wird eingetragen Da unterschiedliche Typen von Notes erstellt werden k nnen diese aufgrund hres identifizierbaren Typs f r verschiedene Aufgaben eingesetzt werden J Methoden J Methoden werden f r Referenzen auf Metaklassen definiert und dadurch einer Metaklasse zugeordnet Wie der Name dieses Konzeptes vermuten l sst werden J Methoden in der Sprache J geschrieben J Methoden werden w hrend der Modellierung durch das Objecteering UML Modeler Tool intern oder direkt von der Benutzerln durch die Aktivierung eines Commands ber das Kontextmen aufgerufen J Code kann entweder durch einen m Objecteering UML Profile Builder internen Editor oder durch einen beliebigen externen Texteditor erstellt werden Die durch das Objectee ring UML Metamodell vordefinierten public oder protected J Methoden der referenzierten Metaklasse oder deren Eltern k nnen redefiniert werden J Attribute Im Objecteering UML Profile Builder ist es m glich Metaattri bute fur J Klassen in Form von J Attributen zu definieren In der evaluierten Version werden nur Klassenattribute als Metaattribute unterstitzt da In stanzattribute durch das Objecteering UML Metamodell fix vorgegeben sind J Attribute werden von J Methoden derselben Klasse verwendet und sind nicht persistent d h die We
34. in ASL formuliert Kapitel 4 Evaluierung Seite 69 Der 1UML Simulator nutzt die durch den 1 UML Modeler erstellten Modelle inklusi ve der Anfangsbedingungen und der Testmethoden um die Modelle durch ihre Aus f hrung zu verifizieren Der BenutzerIn wird durch den 1UML Simulator eine grafi sche Benutzeroberfl che geboten welche die Simulationen zu kontrollieren erlaubt und zus tzlich Objekte Objektzust nde S gnale und ausgef hrten ASL Code visua lisiert Die Benutzeroberfl che des 1UML Simulators Abbildung 4 4 besteht aus einem Hauptfenster f r die Steuerung der Modellausf hrung linker Bereich der Ab bildung 4 4 und aus einblendbaren Tabellen die Informationen ber Objekte Signa le und ASL Variablen beinhalten rechter Bereich der Abbildung 4 4 Im Haupt fenster kann zwischen automatischer Ausf hrung d h bis keine S gnale mehr vor liegen oder benutzerdefinierter Ausf hrung d h d e BenutzerIn kann w hlen ob bis zum n chsten S gnal bis zur n chsten Operationsausf hrung oder bis zur n chs ten Zeile ASL Code in einem Schritt fortgefahren wird gew hlt werden Falls ge w nscht kann die Modellausf hrung in einer Log Datei mitprotokolliert oder aufge zeichnet werden Aufgezeichnete Modellausf hrungen k nnen im 1UML Simulator abgespielt werden und bieten dadurch eine hervorragende Dokumentationsm glich keit f r Tests E UML Simulator KIOK Assiener States File View Exec
35. letzte Anforde rung an die UML Modellierungswerkzeuge eine Export bzw Speicherungsm g lichkeit der Modelle in XMI Dateien 4 4 3 Kernkomponente Die Kernkomponente ist fur die Koordination der einzelnen Werkzeuge des AndroMDA Werkzeuges verantwortlich und wird entweder durch ein ANT Build Skript oder durch ein MAVEN Plugin aufgerufen Speziell f r das Einbinden der MDA Cartridges das Lesen der XMI Datei den Aufbau eines abstrakten Syntax baumes f r die eingelesene XMI Date instanziertes Metamodell und die Durch f hrung der Transformationen der Modellelemente greift AndroMDA auf etablierte Open Source Technologien soweit dese vorhanden s nd zur ck Die Kernkompo nente kontrolliert bzw erm glicht das Zusammenspiel der einzelnen Technologien Gleichzeitig stellt die Unabh ngigkeit von bestimmten Technologien eines der wich tigsten Architekturprinzipien von AndroMDA dar ber exakt definierte Schnittstel len sind neue Produkte in das AndroMDA Framework integrierbar und somit k nnen die mitgelieferten Produkte einfach substituiert werden Damit soll die zuk nftige Entwicklung von AndroMDA gesichert werden und nicht von der Entwicklung der einzelnen Produkte abhangen l www ant org Stand 1 1 2005 2 www maven org Stand 1 1 2005 Kapitel 4 Evaluierung Seite 83 Produkte Framework bernimmt das Einlesen Repository der XMI Date generator generator Tabelle 4 1 mitgelieferte Produkte des AndroMDA
36. mit Hilfe des Objecteering UML Profile Builders er Kapitel 4 Evaluierung Seite 98 stellt werden Zus tzlich sind die mitgelieferten Module durch Vererbung modifi zier bzw spezialisierbar UML Profile fur C Ermoglicht die Verwendung von Design Patterns und Codegenerierung fur C UML Profile fur Java Ermoglicht Java Codegenerierung Reverse Enginee ring Konsistenz zwischen generiertem Code und Mo dell und Design Patterns fur Java tenbankmodell und erm glicht SQL Codegenerierung UML Profile f r EBJ Transformiert ein UML Modell n ein EJB spezifisches Modell erm glicht automatische Codegenerierung in klusive Deployment Informationen und Reverse Engi neering bietet erweiterte Profiles f r die aktuellsten Applikationsserver wie z B Websphere und Weblogic UML Profile f r VB Ermoglicht VB Codegenerierung von UML Modellen UML Profile f r XMI Ermoglicht den Export und Import von Modellen durch XMI UML Profile f r Erm glicht die Generierung von komplettem CORBA CORBA IDL Code UML Profile f r Test Erm glicht die Modellierung von Testf llen Weiters wird ein Tests f r Java Subprofile geboten das den gesamten Java Code fur die ben tigten Tests mittels JUnit generiert UML Profile f r Reverse Erstellt aus COM Schnittstellen automatisch UML Mo COM delle UML Profile f r Doku Generiert Dokumentationen als Microsoft Word oder HTML Dokumente durch einen Dokumentationss
37. nnen sich somit mehr auf die Imple mentierung der Gesch ftslogik konzentrieren Es k nnen weiters Verbesserungen der Entwicklungszeit und der Codequalitat erreicht werden Leider wird durch diesen Ansatz noch nicht das gesamte Potential der MDA genutzt Einen weiteren Problembereich stellen die derzeitigen Transformationen dar Solan ge es seitens der OMG keinen einheitlichen Standard f r eine Transformationsspra che g bt werden Transformationen durch propriet re Sprachen der aktuellen MDA Kapitel 6 Zusammenfassung und Ausblick Seite 138 Werkzeuge definiert Somit ist eine Transformation nur f r ein bestimmtes MDA Werkzeug nutzbar und die Entstehung eines Marktes f r Transformationen nur be grenzt realisierbar Auch das Versprechen von MDA dass d e EntwicklerInnen keine Kenntnisse ber die eingesetzten Softwareplattformen ben tigen w rd zu diesem Zeitpunkt nicht er f llt Die EntwicklerInnen ben tigen sehr wohl Kenntnisse ber die Softwareplatt formen da sie die PIMs mit plattformspezifischen Details markieren m ssen Diese Problematik wird durch die fehlende PSM Ebene in den MDA Werkzeugen zusatz lich verst rkt Nur eines der in dieser Arbeit evaluierten Tools verf gt standardm ig ber eine PSM Ebene und diese auch nur fur die J2EE Plattform Die Vision der OMG dass Softwaresysteme auf CIM Ebene entworfen werden ist in keinem evalu ierten MDA Werkzeug erkennbar Ob sich MDA in n chster Zeit als neue
38. postEvent ok Benutzer berechtigt Yelsef message Login failed catch Exception eil systen SUE printin e tostring message Benutzername existiert nicht initAssignmentORepresenterData anzeigen der Fehlermeldung catch Exception ee System out print In tee Eostr ing END OF PROTECTED AREA 7cf6600500000034 C Kapitel 5 Fallstudie Seite 132 Die Gestaltung der Benutzerschnittstelle erfordert weitere Arbeiten auf Codeebene da im ArcStyler nur die Elemente der Benutzerschnittstelle definiert werden k nnen nicht aber ihre Anordnung und ihre Darstellungsm glichkeiten Somit m ssen Nach arbeiten in den JSP Dateien durchgef hrt werden um das gew nschte Layout zu erhalten Auf die Layoutarbeiten wird aber weiters nicht n her eingegangen da diese in jedem gew hnlichen HTML Editor zu bewerkstelligen sind Da ArcStyler ber eine eigene MDA Cartridge f r den BEA WebLogic Applikati onsserver verf gt und diese f r die Entwicklung der Terminverwaltung eingesetzt wird brauchen keine Anpassungen fur die generierten Deployment Descriptors und SQL Skripte vorgenommen werden Die fur den BEA WebLogic Applikationsserver spezifischen Einstellungen werden bereits durch speziell angepasste Transformatio nen der WLS Cartridge ber cksichtigt 5 3 4 Verteilung und Test Dieser Abschnitt beschaftigt sich mit der Verteilung und dem Test der Terminver waltung Hierf r bietet ArcStyler besonder
39. rfen Ange nommen wir modellieren die Klasse Termin innerhalb eines Kalendersystems dann darf eine Instanz Arzttermin vom Typ Termin zur Laufzeit des Systems auftreten Nun gehen wir eine Ebene h her Warum ist es berhaupt erlaubt 1m Modell eine Klasse zu modellieren Da UML durch ein Metamodell beschrieben wird und in diesem ein Konstrukt Klasse existiert darf eine Klasse Termin in unserem eigenen Modell modelliert werden Diese Klasse Termin stellt eine Instanz der Klasse Class des UML Metamodells dar Das UML Metamodell definiert somit die Syntax und Semantik von Klassen durch die Klasse Class Arzttermin Metamodellebene i l Modellebene l l Instanzebene Abbildung 2 3 Metamodellierung Da ein Metamodell wie UML wieder durch ein Modell beschrieben wird muss die ses Modell selbst wieder in einer wohldefinierten Sprache bezeichnet als Metaspra che deklariert werden Dabei m ssen alle Elemente die zur Spezifikation von UML oder anderen Metamodellen notwendig sind in dieser Metasprache vorhanden sein Von der OMG wird Meta Object Facility MOF als Metasprache f r UML und f r alle anderen Metamodelle der OMG wie z B Common Metadata Warehouse CWM verwendet Es besteht ein groBer Unterschied zwischen einer Sprache wie UML und einer Meta sprache wie MOF Letztgenannte dient prim r der Beschreibung von Modellierungs sprachen und nicht wie UML zur Spezifikation von Softwaresystemen Metaspra chen werden aber
40. sollten MDA Werkzeuge Spezifikationsm glichkeiten f r das Verhalten eines Systems bieten um Simulationen auf Modellebene durchf hren zu k nnen Durch Simulationen auf Modellebene k nnen Fehler lange vor der Code generierung und Verteilung der Softwarekomponenten gefunden werden Meistens wird das Verhalten durch Action Semantic Sprachen und oder Zustandsdiagrammen angegeben S mulationsdurchl ufe sollten mit verschiedenen Startzust nden und Szenarien z B mit unterschiedlichen Signalfolgen simulierbar und protokollierbar sein MS Unterst tzung von Markierungen Bereits in OMG03a werden Markierungen als notwendiges Konzept f r die Aus wahl von Transformationsm glichkeiten eines Modellelements beschrieben MDA Werkzeuge sollten Notationsm glichkeiten f r Markierungen an Modellelementen implementieren Der Anwenderln sollten intelligente Dialoge f r die Vergabe von Markierungen geboten werden um die korrekte Verwendung von Markierungsvari anten zu erm glichen und um unsinnige Markierungen von Elementen zu vermeiden Die Markierungen m ssen bei den Transformationen automatisch einflie en Es sollte auch m gl ch sein Markierungen f r mehrere unterschiedliche Plattformen parallel zu vergeben z B f r EJB und gleichzeitig f r NEI Die angewandten Transformationen m ssen selber eruieren k nnen welche Markierungen f r sie rele vant sind und nicht relevante Markierungen von anderen Plattformen ignorieren M9 User In
41. und weitere Technologien wie z B XMI oder UML Profiles grob skizziert Im Kapitel 3 werden am Beginn die Aktivitaten eines MDA Entwicklungsprozesses identifiziert und anhand dieser Aktivit ten Kriterien f r die Evaluierung von MDA Werkzeuge abgeleitet Abschlie end werden die erh ltlichen MDA Werkzeuge ka tegorisiert und eine kleine Markt bersicht geboten Kapitel 4 beschreibt die bekanntesten Vertreter von kommerziellen und Open Source Werkzeugen Abschlie end wird ein Werkzeugvergleich anhand des in Kapitel 3 definierten Kriterienkataloges angef hrt Damit sollen St rken und Schw chen der Werkzeuge einfach zu eruieren sein Im Kapitel 5 wird anhand einer Fallstudie gezeigt inwieweit die heutigen Technolo gien den von der OMG propagierten MDA Ansatz umsetzen Als Beispielimplemen tierung dient ein Auszug aus dem CALENDARIUM Projekt Die Applikation wird mittels Enterprise Java Beans relationaler Datenbank JSPs und Servlets realisiert Als MDA Werkzeug wird ArcStyler eingesetzt um aus einem PIM ein lauff higes System zu generieren Kapitel 1 Einleitung Seite 15 Im letzten Kap tel dieser Diplomarbeit werden eine Zusammenfassung der Werk zeugevaluierung und ein berblick ber die Erfahrungen der Fallstudie gegeben Weiters wird ein kurzer Ausblick auf die Entwicklungsm glichkeiten von MDA ge geben Da die fur die Fallstudie erstellten Modelle und der aus den Modellen abgeleitete Code u erst umfangreiche
42. welches Zielelement transformiert wurde T4 Modifikation Erstellung von Transformationen Um fur zukunftige Technologieentwicklungen gewappnet zu sein sollten MDA Tools die Erstellung von selbstdefinierten Transformationen anbieten Durch Modi fikationsmoglichkeiten von vorhandenen Transformationen k nnte die Ber cksichti gung von neuen Versionen von Standards oder Plattformen erreicht werden Eine Grundvoraussetzung daf r st aber dass d e Quelldateien der Transformationsspezi fikationen vom Hersteller mitgeliefert werden T5 Debugging Informationen Um einen Einblick in einen konkreten ausgef hrten Transformationsablauf zu ge w hren sollte ein Tool Debugging Informationen f r Transformationen anzeigen Dieses Feature stellt gerade bei fehlerhaften Transformationen eine gro e Hilfestel lung dar da man einen ersten Anhaltspunkt bekommt an welcher Stelle der Fehler in einer komplexen Transformation liegen k nnte T6 Modellierung von Transformationen Um die Erstellung von Transformationsdefinitionen zu erleichtern sollte eine Mo dellierungsm glichkeit f r Modell und Codetransformationen durch MDA Tools geboten werden Aus diesen Modellen sollte der Code fur die Transformationen au tomat sch erzeugt werden da die Transformationserstellung als Spezialfall der mo dellgetriebenen Softwareentwicklung gesehen werden kann Zus tzlich sollten Transformationen das Vererbungskonzept das aus objektorientierten Sprachen be
43. werden UML konforme Konzepte e Referenzen auf Metaklassen Referenzen auf Metaklassen sind Referenzen auf UML Metamodellelementen wie z B Classifier Class oder Package Um Metaklassen durch ein Profile zu erweitern m ssen daf r im Profile Refe renzen auf die zu erweiternden Metaklassen definiert werden Diese Referen zen werden explizit modelliert bzw 1m Meta Explorer angezeigt und sind der Ausgangspunkt fur alle moglichen Erweiterungsmoglichkeiten wie z B Ste Kapitel 4 Evaluierung Seite 104 reotype oder J Methoden Die Erweiterungen werden der Referenz auf die Metaklasse zugewiesen Um die Zugeh rigkeit der Erweiterungen zu den entsprechenden Metaklassen zu gew hrleisten verf gen alle Erweiterungs m glichkeiten ber ein Attribut baseClass vom Typ String das die erweiterte Metaklasse repr sentiert Eine Metaklasse ist ber Referenzen durch beliebig viele verschiedene Profiles erweiterbar Stereotype Stereotype werden verwendet um Metaklassen f r bestimmte Dom nen zu spezialisieren Dies wird 1m Objecteering UML Profile Builder durch das Anf gen von Stereotypen zu Referenzen auf Metaklassen erm g licht Um Stereotype mit einer eigenen grafischen Notation auszustatten werden Icons Bilddateien im bmp oder gif Format angegeben die anstatt der Repr sentation der referenzierten Metaklasse angezeigt werden Schl sselwort Wert Paare Das Objecteering UML Profile Builder Tool wird verwendet um Typen von Sch
44. werden hier be r cksichtigt o Modelltransformation Diese Kategorie evaluiert die Unterst tzung von Modell transformationen Der Bereich Modelltransformation sollte von MDA Werkzeugen stark unterst tzt werden da dieser Bereich den Grundgedanken der MDA darstellt o Artefakterzeugung Hier werden Anforderungen an den Artefaktgenerierungs prozess ber cksichtigt Um ein einsatzfahiges Softwaresystem zu erhalten m s sen Artefakte aus den Modellen erzeugt werden Dies sollte groBteils automa tisch durch Werkzeugunterst tzung erfolgen Die durch Prozessaktivit ten definierten Kategorien werden durch zwei weitere er g nzt Diese sind nicht unmittelbar aus den einzelnen Aktivit ten des Entwicklungs prozesses ableitbar aber dennoch f r die Evaluierung von gro em Interesse o Toolinteroperabilit t Toolintegration Diese Anforderungskategorie besch ftigt sich mit der Nutzung von zuk nftigen oder bereits etablierten Tools wie z B Eclipse oder NetBeans im Entwicklungsprozess Hierf r kann es sich als n tz lich erweisen wohldefinierte Modellaustauschformate oder Schnittstellen f r e1 ne m gliche Integration von Tools in einem MDA Werkzeug anzubieten o konomische Kriterien Die f nfte und letzte Kategorie untersucht die wirt schaftlichen Kriterien eines MDA Tooleinsatzes Eine sinnvolle bzw berechtigte Verwendung von MDA Tools kann nur dann erfolgen wenn die laufenden Ein sparungen die Kosten der Entwicklu
45. zur Erstellung der Control lerschicht Um die Benutzerschnittstelle zu modellieren werden Representer Klassen einge setzt Diese werden als Klassen mit dem Stereotyp Representer notiert F r jede Webseite ist eine eigene Representer Klasse anzugeben welche die Elemente der Benutzeroberflache wie z B Schaltfl chen oder Textfelder enth lt Eine Represen ter Klasse kann somit als Sammlung von Elementen der Benutzerschnittstelle gese hen werden Die Elemente der Benutzerschnittstelle werden der Representer Klasse Kapitel 5 Fallstudie Seite 120 ber einen eigenen Men punkt zugewiesen ber dieses Men k nnen einfache E lemente wie z B Checkboxen oder Textfelder bis hin zu komplexeren Elemente wie z B Frames oder Panels der Representer Klasse zugewiesen werden Es sei aber darauf hingewiesen dass die Spezifikation der Benutzerschnittstelle durch propriet re Erweiterungen erm glicht wird und sich nicht auf anerkannte Modellierungsstan dards st tzt Somit sind diese Benutzerschnittstellendefinitionen nur m ArcStyler nutzbar Um die Steuerung der Benutzerschnittstelle modellieren zu k nnen werden m ArcStyler Accessor Klassen angeboten Diese werden als Klassen mit dem Stereotyp Accessor notiert Eine Accessor Klasse kann eine oder mehrere Representer Klassen steuern bzw anzeigen und weitere Accessor Klassen benutzen Eine Acces sor Klasse und ihre benutzten Representer Klassen werden mit einer Abhangigk
46. 1 MDA Cartridge fur die Erstellung von EJB 1 1 Anwendungen EJB 2 0 MDA Cartridge fur die Erstellung von EJB 2 0 Anwendungen Diese MDA Cartridge wird weiters fur die Erstellung von ap plikationsserverspezifischen MDA Cartridges verwendet WSL 7 EJB Cartridge fur BEA WebLogic Server 7 x WSL 8 EJB Cartridge fur BEA WebLogic Server 8 x Tabelle 4 4 MDA Cartridges f r ArcStyler Zu diesen mitgelieferten MDA Cartridges k nnen jederzeit weitere entweder von MDA Cartridge Source Forge kostenlos beziehbare oder selbst entwickelte hinzu gef gt werden Mit dem Import von neuen MDA Cartridges kann das Modelle rungswerkzeug ber Profiles um neue Modellelemente erweitert werden und zus tz lich kann die MDA Engine um neue Transformationen und Modellverifikationen erweitert werden Die Entwicklung von eigenen MDA Cartridges wird durch die Cartridge Architectu re CARAT erleichtert Durch CARAT wird die Modellierung von MDA Cartridges und weiters die automatische Generierung der Implementierung der MDA Cartridges aus den Modellen erm glicht Somit wird auch f r die Erstellung von Transformationen der MDA Ansatz verwendet und es k nnen Konzepte wie Wie derverwendung und Spezialisierung von MDA Cartridges genutzt werden Die MDA Engine bietet Dienste an die von den MDA Cartridges aufgerufen wer den k nnen beispielsweise das Management von textbas erten Artefakten Dabei bernimmt die MDA Engine den Schutz der manuell programmiert
47. 4 SOFTEAM Objecteering Metamodel User Guide Version 5 3 http www objecteering com pdf doc us Metamodel pdf 12 2 2005 2004 SOFTEAM Objecteering UML Modeler User Guide Version 5 3 http www objecteering com pdf doc us UMLModeler pdf 12 2 2005 2004 Literaturverzeichnis Seite 152 Softo4f Soft04e Soft99 SUN03a SUN03b Will03 SOFTEAM Objecteering UML Document Template Editor User Guide Version 5 2 http www objecteering com pdf doc us DocTemplateEditor pdf 12 2 2005 2004 SOFTEAM Objecteering UML Administrating Objecteering Sites User Guide Version 5 http www objecteering com pdf doc us Administration pdf 12 2 2005 2004 SOFTEAM UML Profiles and the J language Totally control your ap plication development using UML http www objecteering com pdf whitepapers us uml profiles pdf 12 2 2005 1999 Sun Microsystems Java 2 Platform Enterprise Edition Specification Version 1 4 http java sun com j2ee j2ee 1 4 fr spec pdf 1 2 2005 2003 Sun Microsystems Enterprise JavaBeans Specification Version 2 1 http java sun com products ejb docs html 1 2 2005 2003 E Willink UMLX A graphical transformation language for MDA http se2c uni lu tiki se2c bib_download php id 799 1 2 2005 2003
48. Beschreibung oder Spezifikation eines Systems und seiner Umgebung f r einen bestimmten Zweck wie z B die Spezifikation des Verhaltens oder der Datenstruktur Ein Modell wird oft durch die Kombination von grafi schen Notationselementen und Texten repr sentiert OMG03a Kapitel 2 Model Driven Architecture Seite 22 Im Folgenden werden Gemeinsamkeiten der m der Literatur verwendeten Definitio nen zusammengefasst um eine umfassende Definition f r den Begriff Modell m MDA Umfeld zu geben Modelle werden immer durch Sprachen definiert Eine Sprache kann UML eine Programmiersprache oder auch jede nat rliche Sprache sein Um automatische Transformationen zu erm glichen muss in der modellgetriebenen Softwareentwick lung die Definition f r den Begriff Modell eingeschr nkt werden Ein Modell muss in einer wohldefinierten Sprache angegeben werden da diese vom Computer verar beitet werden muss um vollst ndig automatisierbare Modelltransformationen reali sieren zu k nnen Nat rliche Sprachen wie z B Deutsch oder Englisch eignen sich nicht f r die Spezifikation eines Systems da diese vom Computer nicht exakt verar beitet werden k nnen Diese Problematik wird bereits bei der Benutzung von ber setzungsprogrammen sichtbar Au er der Forderung nach Wohldefiniertheit gibt es keine weitere Restriktion der Syntax von Modellierungssprachen Somit ist Quelltext wie z B Java oder C ebenso wie ein graphisches Modell wie z B e
49. Daf r werden Modellelemente im Quellmodell d h auf Modellebene ausgewahlt die auf spezielle Konzepte der Zielplattform abgebildet werden F r diese Auswahl m ssen die Elemente m Quellmodell sozusagen markiert werden Eine Markierung repr sentiert ein plattformspezifisches Konzept und kann zu den Elementen m Quellmodell annotiert werden um zu beschreiben w e diese Elemente bersetzt werden Markierungen beinhalten somit plattformspezifische Details die in einem plattformunabhangigen Modell nicht vorkommen sollten Deshalb werden die Markierungen nicht direkt in einem Modell eingetragen sondern in einer so genann ten transparenten Schicht ber dem plattformunabhangigen Modell annotiert Kapitel 2 Model Driven Architecture Seite 33 EEE Quell modell Transformation Markierungen U Abbildung Plattform modell Abbildung 2 10 Instanzbasierte Abbildungen nach MDA03 Kapitel 10 3 3 Modellelementtypen des Quellmodells besitzen eine Menge von anwendbaren Mar kierungen F r die korrekte Verwendung von Markierungen sollten diese struktu riert vorliegen d h eine Menge von Markierungen die f r alternative Abbildungen eines bestimmten Konzeptes einer Plattform stehen sollten der ArchitektIn n einem Auswahlmen zur Verf gung stehen Damit soll verhindert werden dass ung ltige oder widerspr chliche Markierungen an Modellelementen angebracht werden Po tentielle Markierungen f r Modellele
50. Dokumente darstellen ist dieser Diplomarbeit eine CDROM beigelegt die das gesamte Modell und den gesamten Code der Terminver waltung beinhaltet Im Anhang A werden die Pfade zu den Modellen angegeben und m Anhang B die Pfade zu den Quelltexten und zu den lauff higen Komponenten Kapitel 2 MDA Model Driven Architecture Im Gegensatz zum Kapitel 1 1 in dem die modellgetriebene Entwicklung allgemein betrachtet wird beschreibt dieses Kapitel die theoretischen Konzepte und Grundla gen von MDA MDA die OMG Version der modellgetriebenen Softwareentwick lung basiert auf den OMG Standards Deshalb wird im Unterkapitel 2 1 die ge schichtliche Entwicklung der Ziele der OMG beschrieben und ein berblick ber die wichtigsten OMG Standards gegeben Modelle stehen 1m Mittelpunkt des MDA Paradigmas deshalb werden im Unterkapitel 2 2 die Begriffe Modell und Metamo dell erkl rt Abschlie end werden im Abschnitt 2 3 die unterschiedlichen Modell ebenen von MDA und Transformationen besprochen 2 1 Uberblick Die Object Management Group verfolgte uber mehrere Jahre die Standardisierung des Object Request Broker ORB Diese Aktivit t war ein Bestandteil der Object Management Architecture OMA OMG95 die ein Framework f r verteilte Syste me die auf der Common ORB Architecture CORBA basieren darstellt Ab 1995 begann die Adaption von industriespezifischen Spezifikationen Weiters wurde mit dem Einzug der objektorientierten Programmier
51. Einige UML und MDA Werkzeuge verf gen ber Modell zu Code Transformatio nen wobei diese nicht ver nderbare und auch nicht erweiterbare Transformationen darstellen Der generierte Code beschr nkt sich auf Schnittstellendefinitionen und Klassendefinitionen Die Codegenerierung wird auch nur f r eine beschr nkte Men ge von Plattformen meist Java und C angeboten Da d e Transformationen nicht ver ndert werden k nnen sind alle anderen Plattformen f r die Implementierung des Systems ausgeschlossen Die aktuellen UML Werkzeuge unterst tzen n hren Pro fessional Editions die Codegenerierung f r Java und C aus UML Klassendiagrammen Der generierte Code besteht meistens nur aus Klassen Attri buten und Methodendefinitionen Ein weiterer Bereich von Codegeneratoren entsteht gerade f r das Eclipse Frame work Sie basieren vorwiegend auf zwei Eclipse Tool Projects n mlich Eclipse Mo deling Framework EMF und Graphical Editing Framework GEF EMF verf gt ber ein eigenes Metamodell namens Ecore das gro e hnlichkeiten zu MOF auf weist Weiters besitzt EMF e n eigenes Codegenerator Framework namens Java E mitter Templates JET Mittels GEF k nnen mit relativ geringem Aufwand ausge reifte grafische Modellierungseditoren entwickelt werden Ein weiteres Eclipse Tool Project namens UML2 Project bietet eine Implementierung des UML2 Metamodells l kostenlos beziehbar ber http www eclipse org emf Stand 1 1 2005 2 ko
52. Frameworks Tabelle 4 1 listet die 1m AndroMDA Framework mitgelieferten Open Source Produkte und ihre Aufgabenbereiche im AndroMDA Framework auf Im Folgenden werden die Grundfunktionen dieser Produkte und hre Aufgaben im AndroMDA Framework genauer beschrieben Netbeans MetaData Repository Im Rahmen des Netbeans Projektes von Sun Microsystems wird als Teilaufgabe das Netbeans MetaData Repository MDR entwickelt MDR kann entweder als eigen st ndiges Werkzeug oder n Frameworks verwendet werden Da MDR den MOF Standard der OMG umsetzt ist es m glich Instanzen jedes MOF basierenden Me tamodells zu laden und zu speichern Matu03 Modelle k nnen in MDR importiert oder von MDR exportiert werden Dies wird durch XML Streams bas erend auf dem XMI Standard erm glicht Auf die importierten Modelle kann ber das Java Meta data Interface JMI JCPO2 zugegriffen bzw k nnen Werte der Modellelemente ber diesen Standard modifiziert werden AndroMDA nutzt das MDR um exportierte Modelle in XMI Form zu verarbeiten und einen abstrakten Syntaxbaum instanziertes Metamodell 1m Speicher aufzubau en um den Transformationen Zugriff auf die Modellelemente zu gew hren Velocity Velocity ist eine Open Source Template Engine und ber Apache Jakarta kostenlos beziehbar Die Templates werden in Velocity Template Language VTL einer ein fach gehaltenen aber durchaus machtigen Skriptsprache geschrieben l http www netbeans org
53. M e UML Profile for EDOC OMG04a Enterprise Distributed Object Compu ting Profile wird f r die plattformunabhangige Modellierung von komponen tenbasierten und verteilten Systemen eingesetzt e UML Profile for EAI OMG04b Enterprise Application Integration Profile unterst tzt die Erstellung von lose verbundenen Systemen die ber asyn chrone oder nachrichtenbasierte Methoden kommunizieren e UML Profile for Schedulabitlity performance and time DMGOS Dieses Profile wird fur die Modellierung von zeitlichen und leistungsbezogenen As pekten der Echtzeitanwendungen eingesetzt e UML Profile for QoS and Fault Tolerance OMG04c Durch dieses Profile wird UML durch Quality of Service und fehlertoleranten Konzepten erwei tert e UML Profile for Java and EJB OMG04d Dieses Profile befindet sich 1m EDOC UML Profile und erm glicht die Erstellung von Java basierten PSMs e UML Testing Profile OMG03e Dieses Profil definiert eine Modellierungs sprache fur den Entwurf die Spezifikation und die Dokumentation von Testsuits Die Trennung von der Problemstellung und der plattformspezifischen Implementie rung wird auch im Logo von MDA angedeutet Rund um die Modellierungstechno logien werden aktuell genutzte Technologien aufgelistet die Zielplattformen fur die Modelltransformationen darstellen Die wichtigsten Softwareplattformen sind Com mon Object Request Broker Architecture CORBA J2EE und NET Fur den Mo dellexport bzw fur
54. Modellie rungssprachen der OMG definiert werden M3 Ebene Metametamodell Die Elemente der M2 Ebene k nnen als Instanzen der bergeordneten M3 Ebene angesehen werden Die Elemente auf M2 und M3 haben wieder die gleiche Bezie hungsart wie Elemente auf MO und M1 oder Elemente auf M1 und M2 Dabei stellen Elemente auf M3 Kategorisierungen von Elementen auf M2 dar M3 soll allgemein als Grundlage fur die Erstellung von Metamodellen Modellierungssprachen dienen Deshalb wird diese Ebene auch Metametamodellebene genannt Die OMG setzt die M3 Ebene mit MOF gleich und dadurch sind alle OMG Sprachtechnologien Instan zen von MOF Theoretisch konnten noch weitere Ebenen tber M3 bzw MOF eingefuhrt werden Doch wie vorhin schon beschrieben wird diese unendliche Problemverschiebung mit einer reflexiven M3 Ebene vermieden Au erdem w rde eine weitere Ebene keinen Abstraktionsgewinn fur die praktische Modellierung bezwecken Kapitel 2 Model Driven Architecture Seite 26 i MOF 7 instanceOf d instanceOf M2 UML Attribute l d Of instanceOf A e instanceOD Termin Mi x Modell name String 1 l I MO representedBy instanzen Abbildung 2 5 Metamodellhierarchie der OMG 2 3 MDA Konzepte In diesem Unterkapitel werden die Hauptkonzepte der Model Driven Architecture wie Computation Independent Model Platform Independent Model Platform Speci fic Model und Platform Model
55. RKZEUGE nassen emule ened 39 hed ol MIO CELLET SITCHIN OSIM VION sacra cues caesar taeda cai E a sea 41 3 2 2 Modeiltroanstormagiionsbkriterien cece cece cece cece cece eke cee eee EEE Ee EEE EEE EEE EEE EE EEE EERE EEE 47 3 2 9 Artejalleenerieruneskfilenen nn 49 3 2 4 Toolinteroperabilit t Toolintegration sinc woccts eins naar 50 Eeer EE Ee 52 3 3 KATEGORISIERUNG VON MDA WERKZEUGE ssssssesssessenssesssessssrsecsssessecsseesseesseresersseresereseresee 55 3 921 EXCCHIADIE UML W KEU E sn a aa 33 3 3 2 lechnolosiespezijische E 59 39 9 Lieni iche MDAW CPZ CN OC sic tits een een 60 EE 61 KAPTERL 42 EVAL ULE RING u u080 0e ea en 63 SEET 64 F2NU MENGES re ea ee 67 EE 68 testen eer deene ienalieiieueler ee 69 A SOPLINATN ae ee ee ee ee ee N ee 70 43 2 Abstr ktion ebenen Eeer Ee e 71 4 3 3 Anpassungsm glichkeiten von OptimalJ ccc EEE EEE 76 AA ANDROMDI ee rennen Ike ei 79 R E T O a LOE NSE AE E S S A E AE S OE S E A E 79 dA Moderan STOO sE es E TA EN NE 81 4 4 3 Kern kOMPOREN euere 82 EE ee se Sursee 85 4 4 5 Ablauf eines Entwicklungsprozesses mit ANUVOMDA c ccc cece cece cece cece cece eee eeeeeeeeeeeees 85 Eeer iere 87 Ee 87 See caine alias ane Mins See sana tte co 88 4 5 9 MDA Gartridees MDA EnSiNe un ae EE 90 GD MOAelPEDOSHOr E 91 LISTO Adapter Standard nun alerts 92 4 6 OBJECTEERING UML 2452 ee ea a u eceaseceecaeseaest 92 SEET ie 93 4 0 2 OD eeter nV OME Modeler E 94 4 6 3 Objecteering UML Pro
56. Stand 1 1 2005 Kapitel 4 Evaluierung Seite 84 F r den Transformationsprozess werden eine Templatedatei und eine Kontextdatei als Eingaben benotigt Durch die Transformation wird eine Datei produziert die ein durch die Templatedatei beschriebenes Format besitzt Wahrend eines Transformati onsprozesses werden bestimmte Stellen Generierungsvariablen im Template durch Daten aus der Kontextdate substituiert Beispielsweise werden Werte von den Mo dellelementen in die Templates eingesetzt und dadurch wird der gew nschte Code generiert Bend04 AndroMDA nutzt Velocity um aus dem abstrakten Syntaxbaum Quelltext wie z B Java Klassen oder SQL Skripte zu generieren Da Velocity als erster Codegenerator im AndroMDA Framework verwendet wird k nnen f r den zweiten Codegenerator XDoclet Metadaten im Quelltext angegeben werden Damit ist es m glich die Transformationsdefinitionen einfacher und bersichtlicher zu gestalten XDoclet XDoclet ist ein Open Source Codegenerator der ber das Open Source Portal Sour ceForge net kostenlos bezogen werden kann Die notwendigen Informationen f r den XDoclet Codegenerator werden ber sogenannte XDoclet Tags als Kommentarform im Quelltext hinzugef gt Mithilfe von XDoclet k nnen diese Metadaten ausgewer tet und daraus Artefakte wie z B Deployment Descriptors oder remote und local Schnittstellen f r Enterprise Java Beans generiert werden Die automatische Erzeugung wird durch Temp
57. TECHNISCHE UNIVERSIT T m Wien TU Wien VIENNA UNIVERSITY OF TECHNOLOGY bbads Business Informatics Group Institut fur Softwaretechnik und Interaktive Systeme Model Driven Architecture in der Praxis Evaluierung aktueller Entwicklungs werkzeuge und Fallstudie Diplomarbeit zur Erlangung des akademischen Grades eines Magister der Sozial und Wirtschaftswissenschaften eingereicht bei o Univ Prof Mag Dipl Ing Dr Gerti Kappel mitbetreuender Assistent Dipl Ing Dr Gerhard Kramler Manuel Wimmer Wien 8 M rz 2005 Eidesstattliche Erkl rung Ich erkl re an Eides statt dal ich die vorliegende Arbeit selbst ndig und ohne fremde Hilfe verfasst andere als die angegebenen Quellen nicht ben tzt und die den benutzten Quellen w rtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe Wien 8 M rz 2005 Manuel Wimmer Danksagung Ich m chte mich bei o Univ Prof Mag Dipl Ing Dr Gerti Kappel und Dipl Ing Dr Gerhard Kramler f r die Anregung zu dieser Diplomarbeit und f r die Unterst t zung bei der Erstellung der Arbeit bedanken Weiters m chte ich mich ganz beson ders bei meiner Mutter Ingrid Wimmer bedanken die mir durch thre finanzielle und moralische Unterst tzung mein Studium und dadurch auch diese Diplomarbeit er m glichte Au erdem bedanke ch mich be den KorrekturleserInnen Michael Edin ger Christian Schlosser und Sabine Wimmer Kurzfassung Model Driven Arc
58. Zuge eines Projekts mit MDA Ansatz wie beispielsweise die Transformation von PIM zu PSM oder vice versa Verf gt en MDA Werkzeug ber unterschiedliche Modellebenen so sollten auch automatische Transformationen zwischen diesen angeboten werden Bei der automatischen Erstellung bereits vorhandener Modelle muss darauf geachtet werden dass manuelle Ver nderungen im Modell erhalten bleiben d h die manuellen Ande rungen sollten nicht durch neue Transformationen berschrieben werden T2 Modell zu Code Transformation Ein Hauptziel der MDA ist die automatische Generierung von Code aus Modellen Daher sollte em MDA Tool eine Funktion f r die Generierung von Artefakten aus Modellelementen anbieten Dabei sollte nicht nur Programmcode erzeugt werden sondern auch alle f r die erfolgreiche Inbetriebnahme der Software notwendigen Dateien Man denke dabei an XML Dateien wie Deployment Descriptors oder an SQL Skripte Kapitel 3 MDA Werkzeuge Seite 48 T3 Traceability zwischen Quell und Zielelementen Der Zusammenhang von Modellelementen auf unterschiedlichen Modellebenen und daraus resultierenden Codefragmenten wird ohne Zusatzinformationen auf den ersten Blick schwer erkennbar sein Deshalb sollten Tools die Transformationsabh ngigkei ten auf unterschiedlichen Ebenen durch zus tzliche Informationen kennzeichnen Ein weiteres Feature w re eine Log Datei f r den Transformationsprozess in der mitpro tokolliert wird welches Quellelement in
59. aden werden F r die Terminver waltung werden insgesamt zwei MDA Cartridges ben tigt n mlich eine f r das EJB Subsystem und eine weitere f r das Web Subsystem Die Abbildung 5 4 zeigt die ausgew hlten MDA Cartridges f r das Terminverwaltungsprojekt Sobald die ben tigten MDA Cartridges ausgew hlt wurden stehen plattformspezifische Daten typen Stereotype und Schl sselwort Wert Paare als Modellelemente zur Verf gung Die MDA Cartridge f r das EJB Subsystem sollte ber Modellelemente f r die Kon zepte der J2EE Plattform verf gen und zus tzlich Unterst tzung f r den Applikati onsserver BEA WebLogic Server bzw f r den Datenbankserver PointBase bieten Diese Anforderungen erf llt die mit ArcStyler standardm ig mitgelieferte MDA Cartridge BEA WebLogic Server 8 1 die kurz mit WLS Cartridge bezeichnet wird Die MDA Cartridge f r das Web Subsystem sollte Unterst tzung fur das MVC Muster und fur die Erstellung von Web Benutzeroberflachen bieten Zusatzlich ware eine Unterst tzung des Webservers Tomcat w nschenswert um eine rasche Test m glichkeit f r Prototypen zu bieten Mit dem ArcStyler Werkzeug wird standard m ig eine WebAccessors Cartridge mitgeliefert welche den Anforderungen f r die Erstellung des Web Subsystems entspricht Kapitel 5 Fallstudie Seite 117 MDA Configuration a Global u Licenses 6 Project Manager I Project Configur S85 Gui Manager ae Perspectives 5 8 Logs Description
60. alit t wie z B plattformspezifische Benutzeroberflachener stellung oder automatische Generierung von Verteilungsinformationen f r bestimmte Herstellerplattformen bieten Die EntwicklerInnen sollten sich aber im Klaren sein dass s e f r d e unterst tzte Plattform ausgezeichnete Hilfestellung bekommen aber gleichzeitig auch in dieser gefangen sind Speziell f r Java und NEI werden einige spezialisierte Werkzeuge angeboten Beispielsweise unterst tzt Compuwares Opti malJ die Entwicklung von Softwaresystemen die auf J2EE bas eren Dot Net Buil ders Constructor fokussiert auf die Erstellung von Systemen welche auf der NET Plattform basieren IBM bietet zwei verschiedene Versionen seines Rational XDE Werkzeuges an eine Version f r d e Erstellung von EJB Systemen und eine weitere f r die Entwicklung in NET Tabelle 3 3 gibt einen groben berblick ber platt formspezifische MDA Werkzeuge Kapitel 3 MDA Werkzeuge Seite 60 Toolhersteller Produkt unterst tzte Homepage Plattform Optimal J2EE http www compuware com Dot Net EI bell http www dotnetbuilders com EI Sei XDE Wai NET http www 306 1bm com software awdtools developer java f r J2EE http www 306 1bm com software awdtools developer visualstudio f r NET BITPlan UML2PHP PHP http www uml2php com Web Models 12EE NET Tabelle 3 3 plattformspezifische MDA Werkzeuge Fur die Evaluierung in Kapitel 4 wird OptimalJ als Vertreter der technol
61. ation welches Element bzw welche Elemente des Zielmodells ein Ele ment des Quellmodells repr sentiert bzw repr sentieren wird in OMG03a Kapitel 3 4 Abbildung genannt Es gibt verschiedene Ans tze welche Informationen f r Abbildungen herangezogen werden Zusammenfassend k nnen grob drei Ans tze unterschieden werden n mlich Typbasierte Abbildungen Instanzbasierte Abbildun gen und Musterbasierte Abbildungen Typbasierte Abbildungen Eine typbas erte Abbildung definiert seine Abbildungsregeln mit Typen des Quell und Zielmodells d h auf Metamodellebene Eine Regel spezifiziert wie ein be stimmter Typ des Quellmodells auf einen Typ oder mehrere Typen des Zielmodells abgebildet wird Metamodellabbildungen sind eine spezielle Form von typbasierten Abbildungen wobei die Typen der Modellelemente durch das MOF Modell spezifi ziert werden sollten Somit reicht es aus die Transformationsregeln auf Metamodell ebene zu definieren Die Modelle auf M1 Ebene brauchen in die Transformationsde finition nicht einzuflie en da die Regeln auf die Typen der Elemente der Modelle angewendet werden Kapitel 2 Model Driven Architecture Seite 32 BEN Quell verwendet Quellmodell modell typen Transformation Abbildungs regeln Zielmodell typen Abbildung 2 9 Typbasierte Abbildungen nach MDA03 Kapitel 3 10 1 Instanzbasierte Abbildungen Eine weitere Abbildungsmoglichkeit stellen instanzbasierte Abbildungen dar
62. ationsanforderungen zu verwirklichen MDA Tools sollten auch die Generierung von HTML Dokumentationen f r Modelle anbieten HTML Dokumentationen bieten eine statische Sicht auf die Modellele mente Weiters haben sie den Vorteil dass sie rasch ber einen Browser angezeigt werden k nnen ohne e n Modellierungstool zu verwenden In der erstellten Doku mentation sollte f r jedes Diagramm eine entsprechende Grafik enthalten sein Eine Navigation durch das gesamte Modell ist ber Hyperlinks einfach zu realisieren 3 2 4 Toolinteroperabilit t Toolintegration Diese Kategorie l stet Anforderungen an die Erweiterung von MDA Tools bzw die Integration von f r den Entwicklungsprozess n tzlichen Tools wie grafische Model lierungseditoren oder Programmier IDEs auf Da sich am UML Toolsektor und am IDE Toolsektor bereits mehrere ausgereifte Tools etabliert haben und EntwicklerIn nen diese Produkte seit mehreren Jahren verwenden sollte eine M glichkeit geboten werden auf diese Tools auch im MDA Entwicklungsprozess zur ckzugreifen Grafi sche Modellierungseditoren k nnten entweder ber wohldefinierte Schnittstellen n das MDA Tool integriert werden oder die Modelle k nnten ber das XMI Format zwischen den Tools ausgetauscht werden F r die Integration von Programmier IDEs ist heutzutage die automatische Erstellung von Projektdateien f r die jeweilige IDE ausreichend da diese noch keinen MDA Ansatz unterst tzen und deshalb nur f r d e
63. attet sind Im zweiten Kapitel dieser Arbeit wurden Markierungen besprochen und die Anfor derung postuliert dass f r Markierungen intelligente Auswahloptionen vorgesehen werden sollten um die EntwicklerIn bei der korrekten Auswahl zu unterst tzen ArcStyler realisiert diese Anforderung durch einen eigenen Men punkt MDA Marks Abbildung 4 12 zeigt als Beispiel f r Markierungen im ArcStyler ein Men f r die Markierung eines Elements f r die Zielplattform Enterprise Java Beans Zuvor wur de dieses Element mit dem Stereotyp ComponentSegment versehen wodurch die Markierungen f r EJB automatisch verf gbar werden um die n tigen Entscheidun gen uber den Typ der Bean wie EntityBean SessionBean oder MessageBean oder State Management statefull oder stateless zu treffen Kapitel 4 Evaluierung Seite 90 Class Specification General Attributes Operations Template Parameters Inner Elements Relations Stereotypes Tagged Values Constraints MDA Marks ArcStyler Java WebService EJB 1 1 2 0 WLS 6 8 CMP WLS6 8 Core Profile JNDI Name Local JNDI Name BeanType Session GenRemotelnterfaces True GenLocallnterfaces True FeatureDfltInterface Remote e PersistenceManagement Cartridge Default isReentrant False e StateManagement Stateful TransactionType Container ContainerTransaction Required SessionSynchronization False CommitOption Cartridge Default Timeout env entries CMP Version AbstractSchemaName
64. beiten werden notwendig Gesch tzte Bereiche sollten von MDA Tools unbedingt unterst tzt werden und dies nicht nur bei Programmcodedateien wie etwa Java Klassen sondern auch bei allen sonstigen Textdateien wie z B SQL Skripten oder XML Dateien A2 Debugging Informationen fur Artefaktgenerierung Wie schon bei der Anforderung T5 Debugging Informationen fur Modelltransfor mationen besprochen wurde sollten MDA Tools fur die Artefaktgenerierung ebenso Debugging Informationen bieten Gerade fur das Testen von neuen Generierungs spezifikationen bietet dieses Feature einen gro en Nutzen fur die rasche Fehlerfin dung A3 Hohe Codequalit t Kapitel 3 MDA Werkzeuge Seite 50 Da meistens keine 100 1ge Codegenerierung durchf hrbar ist m ssen Entwickle rInnen Codefragmente zu generierten Codeteilen manuell hinzuf gen Hierf r ist es von besonderer Bedeutung dass MDA Tools den generierten Code gut strukturieren und die Codeteile durch Kommentare beschreiben Hohe Quelltextqualit t tr gt eini ges zur Produktivitatssteigerung beim manuellen Hinzuf gen von Codefragmenten bei A4 Automatische Dokumentationserstellung Ein ausgereiftes MDA Werkzeug sollte zumindest eine Moglichkeit der automati schen Erstellung einer Dokumentation welche sowohl grafische Diagramme als auch im Modell enthaltene Textfragmente umfasst bieten Flexible Dokumentati onsgeneratoren sollten veranderbare Templates anbieten um individuelle Dokumen t
65. bjecteering UML Modeler welche in vier Hauptkategorien eingeteilt werden kann Der Explorer Nummer 1 in der Abbil dung 4 14 zeigt in einer hierarchischen Sicht einen Baum der alle Modellelemente eines Projektes beinhaltet Er wird verwendet um Elemente eines Modells wie z B Klassen Attribute und Operationen zu erstellen und zu visualisieren Der Eigen schaften Editor Nummer 2 in Abbildung 4 14 beinhaltet mehrere Karteikarten die zum markierten Modellelement und dessen zugeteilten Elementen n here Informati Kapitel 4 Evaluierung Seite 95 onen und Befehle anzeigen Die Konsole Nummer 3 n Abbildung 4 14 beinhaltet Feedback f r die EntwicklerInnen wie Traces Fehlermeldungen Warnungen und vieles mehr Das Hauptfenster Nummer 4 n Abbildung 4 14 zeigt das eben ausge w hlte Diagramm E objecteering UML Modeler demoVendingMachineCpp File Edit View Graph Tools Windows E ElementsDispensed EI Food name string myType typeOfFood create amp Drinks H Sweets Caramels Biscuits e EI Tea Wed A EI Mints Gingerbread ji A ABER o H zc EH Y M description 7 is_a Food ElementsDispensed Food Hed Jo GR Traceability editor Items e Editing the C Projects cpp ElementsDispensed Drinks c file Editing complete the C Projects cpp ElementsDispensed Drinks cx file has been retrieved Abbildung 4 14 Hauptansicht des Objecteering UML Mod
66. chab mentationsgenerierung lonen Editor k nnen neue Schablonen erstellt werden UML Profile f r Design Automatisiert die Verwendung von Entwurfmuster Patterns durch Modelltransformationen Metrics Erm glicht die quantitative und qualitative Auswertung von Modellen auf Grundlage bekannter objektorientier ter Metriken UML Profile f r CMS Bietet Subprofiles f r ClearCase CVS und viele mehr UML Profile f r Requi Erm glicht eine ausf hrliche Anforderungsanalyse mit Kapitel 4 Evaluierung Seite 99 rementsanalyse tels UML und die Traceability zwischen Anwendungs fallen und weiteren Modell bzw Codeteilen UML Profile f r SPEM Erm glicht die Modellierung von Softwareerstellungs prozessen durch das von der OMG standardisierte Soft ware Process Engineering Management Profile UML Profile f r EDOC Erm glicht d e Modellierung von Enterprise Distributed Object Computing wird aber erst mit der Einf hrung von UML 2 0 in Objecteering UML erh ltlich sein Tabelle 4 5 mitgelieferte Module von Objecteering UML 4 6 3 Objecteering UML Profile Builder Das Objecteering UML Profile Builder Tool wird verwendet um UML Profiles fur den Einsatz im Objecteering UML Modeler zu entwerfen und zu implementieren UML Profiles enthalten Elemente welche die plattformspezifische Modellierung Modelltransformationen Artefaktgenerierung und die Validierung von erstellten Modellen im Objecteering UML Modeler erm glic
67. che ber l ngere Zeit als konstant gelten zumindest l nger als die meisten Softwareplattformen k nnen die gespeicherten PIMs f r neuere Implemen tierungen gen tzt werden Im Laufe der Zeit verschwinden Plattformen vom Markt und wiederum entstehen neue Plattformen bzw neue Versionen von Plattformen wobei die Neuen beispielsweise durch bessere Performance und mehr Sicherheit ausgezeichnet s nd und eine schnellere Entwicklung von Applikationen erm glichen F r eine Unternehmung ist die IT Infrastruktur ein wichtiger Wettbewerbsfaktor und daher bleibt der laufende Umstieg auf neuere Technologien bzw auf neuere Versio nen der Technologien unausweichlich Geht eine Unternehmung nach dem MDA Paradigma vor stellt ein Technologie wechsel em geringeres Problem dar da nur eine Transformation zur Erstellung der neuen Applikation ben tigt wird Kapitel 1 Einleitung Seite 8 Die Entwicklung von neueren Versionen von Plattformen tritt bei weitem fters auf als ein vollst ndiger Paradigmenwechsel Abbildung 1 4 gibt einen berblick ber die zeitliche Entwicklung aktueller Softwareplattformen SE up D gt Hp gt 2830 XML gt XML DTD Schema Zeit Abbildung 1 4 zeitliche Entwicklung von aktuellen Plattformen Aber auch die Evolution von Plattformen wird durch die korrekte Isolation der Do m nenlogik von den technischen Spezifika gel st Somit bleiben m hsame Re Implementierungen von vorhandenen Programmen er
68. chen Quell und Zielelemen Ges fo ten T4 Modifikation Erstellung von Transformationen 15 Debugging Informationen fo EA T6 Modellierung von Transformationen Tabelle 4 7 Modelltransformationsanforderungen Kapitel 4 Evaluierung Seite 109 Artefaktgenerierungskriterien Inu liu OP AN AR oB A1 gesch tzte Bereiche lele lalol lo A2 Debugging Informationen f r Artefaktgenerie alelefolel rung A3 hohe Codequalit t Jill A4 automatische Dokumentationserstellung O 0 O O _ Tabelle 4 8 Artefaktgenerierungsanforderungen Toolinteroperabit t Toolintegrationkriterien NU 1 OP AN AR OB 1 UnerstitzangvonxME fol e Bine Lf fot 18 Unterst tzung von ProgrammierDEs o o Tabelle 4 9 Toolinteroperabilitats Toolintegrationsanforderungen konomische Kriterien NU TU OP AN AR OB DER ERERESESER 02 unterschiedliche Versionen o Lo 03 angebotene Schulungen Of 04 Werkzeugdokumentation O OL JO 05 Supportmiglichkeit LO OL O6 Benutzerfreundlichkeit_ OL OL Of Tabelle 4 10 konomische Anforderungen Kapitel 5 Fallstudie Dieses Kapitel beschreibt eine Fallstudie in der eine mehrschichtige Webapplikation anhand des MDA Ansatzes implementiert wird Dabei besitzt die Webapplikation nur eine minimale Funktionalit t da der
69. chnittstellen fur die Manipulation von MOF basierten Modellen und ihren Instanzen definiert Diese Schnittstellen werden entweder durch CORBA IDL oder Java beschrieben Fur den Bereich Data Warehouse wurde von der OMG ein eigenes Metamodell namens CWM entwickelt CWM unterst tzt den gesamten Lebenszyk lus vom Entwurf ber die Entwicklung bis zur Wartung der Data Warehouse Applikationen Ein weiterer Einsatzbereich von CWM stellt die Modellierung von Datenbankschemata f r Data Warehouse Applikationen dar In der Abbildung 2 1 werden zwar einige Technologien der OMG angegeben jedoch gibt es noch weitere die enormes Potential f r MDA besitzen Zu diesen Technolo gien z hlen Object Constraint Language OCL OMGO3d und UML Profiles Kapitel 2 Model Driven Architecture Seite 18 OCL erlaubt die textuelle Spezifikation von Einschrankungen die durch grafische Notationen nicht oder nur schwer dargestellt werden k nnen UML ist durch UML Profiles entweder fur bestimmte Softwarebereiche wie z B verteilte Systeme oder Echtzeitsysteme oder fur bestimmte Softwareplattformen wie z B EJB oder CORBA erweiterbar Erweiterungen durch UML Profiles verandern aber nicht das UML Metamodell Somit ist die Standardisierung und Interoperabilitat von UML sichergestellt Folgende UML Profiles wurden bereits von der OMG standardisiert e UML Profile for Corba OMGOO Dieses Profile erm glicht die Transforma tion eines PIMs in ein CORBA spezifisches PS
70. chritt in der Ge schichte der Softwareentwicklung Im Mittelpunkt dieses Ansatzes stehen Modelle die Softwaresysteme auf unterschiedlichen Ebenen beschreiben Die Aufgabe der Kapitel 1 Einleitung Seite 3 Modelle ist nicht nur die Kommunikation zwischen EntwicklerInnen ArchitektInnen und KundInnen oder die Dokumentation des Systems sondern die Modelle werden fur die Gewinnung neuer verfeinerter Modelle und weiters f r die Generierung von lauffahigem Code verwendet Im MDA Paradigma werden primar zwei Arten von Modellen unterschieden e Platform Independent Model PIM enthalt nur den Problem bzw Anwen dungsbereich jedoch keine Details ber Software bzw Hardwaretechnolo gien e Platform Specific Model PSM enth lt zus tzlich zum PIM Details ber die verwendeten Software bzw Hardwaretechnologien Im Idealfall l uft der bergang von einem plattformunabh ngigen Modell auf ein plattformspezifisches Modell vollst ndig automatisiert ab und weiters wird aus dem plattformspezifischen Modell automatisch lauffahiger Code transformiert Abbildung 1 1 beschreibt den Kerngedanken des MDA Paradigmas PIM Transformation PSM Abbildung 1 1 Modell Transformation PIM gt PSM Die automatische Erstellung von Software aus plattformunabh ngigen Modellen wird mit der Einf hrung einer weiteren Abstraktionsebene das PIM stellt eine neu artige Abstraktionsebene dar in der Softwareentwicklung ermoglicht In der Ver
71. cklung e Modelle werden nur als Dokumentation verwendet e Unterschiede zwischen Modell und Code o nderungen im Modell werden auf Codeebene nicht automatisch bertragen und vice versa Der letzte Beisatz verursacht vom Code abweichende Dokumentationen da am Ende eines Projektes wegen Zeitdruck viele nderungen nur mehr auf Codeebene durchgef hrt werden e Keine Modelltransformationen o Keine ausgereiften standardisierten Transformationssprachen o Nur geringe Werkzeugunterst tzung Um die Verwendung von Modellen im Softwaredesign voranzutreiben und die vor her erw hnten Limitationen zu beheben bedarf es an wohldefinierter Modelle Mo delle im Sinne der MDA sind alle im Zuge eines Entwicklungsprozesses entstande nen wohldefinierten Modelle des zu entwickelnden Softwaresystems Diese Modelle konnen auch unterschiedliche Sichtweisen auf ein Softwaresystem ermoglichen Da Modelle in verschiedenen Varianten auftreten f llt eine exakte Definition schwer Darum werden vorerst einige in der MDA Literatur verwendete Definitionen ange f hrt e Eine Beschreibung eines Systems oder Teile davon geschrieben in einer wohldefinierten Sprache Eine wohldefinierte Sprache ist eine Sprache mit wohldefinierter Form Syntax und Bedeutung Semantik die f r die auto matische Verarbeitung durch Computer geeignet ist Klep03 e Eine Repr sentation eines Teils der Funktion der Struktur oder des Verhal tens eines Systems OMG01 e Eine
72. cutable UML Modellen verantwortlich 1CCG steht f r Intelligent Configurable Code Gene rator und ist f r die Transformation von Executable UML Modellen zu Code zust n dig Es sind Versionen von IUML ICCG f r Windows NT4 2000 XP und f r Solaris ab Version 2 5 verf gbar Die Anwendung von 1UML iCCG befindet sich wie be Nucleus BridgePoint im Embedded Systems Bereich in dem bereits mehrere erfolg reiche Projekte umgesetzt wurden Kapitel 4 Evaluierung Seite 68 Fur die Evaluierung wird eine Testversion von 1UML genannt 1UMLite eingesetzt Diese Testversion ist in einigen Bereichen nur eingeschr nkt verwendbar Die f r die Evaluierung relevanteste Einschr nkung ist dass Executable UML Modelle nur durch den 1UML Simulator ausgef hrt werden k nnen da in der Evaluationsversion keine Codegenerierungsfunktion vorgesehen ist Deshalb wird auch das 1CCG Werkzeug f r die Konfiguration des Codegenerators nicht mitgeliefert Da keine kostenlose Version des 1CCG Tools angeboten wird wird in dieser Arbeit die Code generierung in 1UML iCCG nur theoretisch basierend auf den Dokumentationen zu UML KC02a und iCCG KC02b betrachtet 4 2 1 iUML Die Evaluationsversion 1UMLite besteht aus zwei Hauptkomponenten n mlich aus dem iUML Modeler und dem iUML Simulator Der iUML Modeler bietet der An wenderIn die M glichkeit konsistente Executable UML Modelle zu erstellen und in einer Modelldatenbank zu speichern Der 1UML Simulator wird e
73. d danach in J2EE Artefakte transformiert Die Archi tecture Edition erweitert die Professional Edition und ist f r den Gebrauch von auf die J2EE Plattform spezialisierten ArchitektInnen vorgesehen die neue Modelltypen oder neue Patterns erstellen bzw mitgelieferte Modelltypen oder Patterns modifizie ren Unabhangig von der Edition lauft OptimalJ auf Windows NT 2000 XP Sun Solaris und Linux Prinzipiell sollte OptimalJ jedoch auf jeder mit einer Java Virtual Machi ne ausgestatteten Plattform laufen Auf der Applikationsserverebene sollte OptimalJ mit jeder J2EE kompatiblen Plattform zusammenarbeiten Mit OptimalJ werden fol gende Open Source Tools mitgeliefert Tomcat als Web JBoss als Applikations und Solid als Datenbankserver Diese mitgelieferten Technologien werden verwen det um eine in OptimalJ integrierte Testumgebung zu schaffen Ab Version 3 1 wur de die Testumgebung fur weitere Applikationsserver wie z B BEA s Weblogic 8 1 oder IBM s WebSphere 5 erweitert Uber konfigurierbare Systemeigenschaften las sen sich beliebige Plattformen fur die Testumgebung festlegen Diese Konfigurati onsm glichkeit unterst tzt die automatische Erstellung von Deployment Descriptors fur spezifische Plattformen 4 3 2 Abstraktionsebenen in Optimal Wie durch das MDA Paradigma gefordert unterscheidet OptimalJ bei der Entwick lung eines Softwaresystems zwischen Modellen und der Implementierung Um diese Trennung entsprechend umzusetzen
74. d getestet werden 5 3 Durchfuhrung des Projektes In diesem Unterkapitel wird die Entwicklung der Terminverwaltung erlautert Als MDA Werkzeug wird ArcStyler eingesetzt das ein markiertes PIM direkt zu Code transformiert und keine PSM Modellebene unterst tzt Daher beschr nkt sich das Vorgehensmodell des Entwicklungsprozesses auf Modellierung Modell zu Code Transformation Implementierung der restlichen Funktionalit t und Verteilung bzw Test Die zu erstellende Terminverwaltung wird m zwei Subsysteme unterteilt Das erste Subsystem umfasst die Geschaftslogik und die persistenten Daten der Anwendung Dieses Subsystem wird als eine EJB Applikation implementiert und 1m J2EE Appli kationsserver bzw Datenbankserver ablaufen Im Folgenden wird dieses Subsystem als EJB Subsystem bezeichnet Das zweite Subsystem beinhaltet die Web Benutzer oberflache und die Steuerung der Anwendung Realisiert wird dieses Subsystem durch JSPs fur die Benutzerschnittstelle und Java Servlets fur die Steuerung Die l zu beziehen ber http www bea com Stand 1 12 2004 2 zu beziehen ber http jakarta apache org tomcat Stand 1 12 2004 Kapitel 5 Fallstudie Seite 116 Artefakte dieses Subsystems werden sp ter im Webserver ablaufen Im Folgenden wird dieses Subsystem als Web Subsystem bezeichnet 5 3 1 Modellierung Als erster Schritt w rd m ArcStyler ein neues Projekt angelegt Danach m ssen die ben tigten MDA Cartridges in das Werkzeug gel
75. dellelemente und Profiles visualisiert Der Hauptbereich der Modellierungsschicht wird zur Erstellung von UML Diagrammen genutzt Kapitel 4 Evaluierung Seite 89 az AreStylar Kalandar Diimagisterikalendar aspri Fie Edt View Layout Diagrams Options Tools Teamwork Modeling Window Help am w Generate v Modoting Perspective LML Toal i ASTETE EELE RE A F A LA SW A PD amp a UML Proecs Dima etengdefl alendor xml A main Late 0 mplernenialson A classes A apnerpolgogp opoendaopruwsg lt 2 Bea EF fo Data 1 ewe Ace SD n A classes A classes di RoctAccessoDependancias BS Conpoament View Pa Gaia types Ca eb alindar ie BS MOA Profiles i Relations Ps abmelden Es anrnelden B5 eintraghinzuhagen Bo ejbCalandanum E ansich E Layout E Mitte ben RootAccesuor ei Stari BS urien A Ront rcCpzssartampppngercip ie E flow spacifies RootAcceasec ch SC LUinitledYsnecihes Start e Ke ansicht Abbildung 4 11 Modellierungsperspektive des ArcStylers Um den Anforderungen an MDA gerecht zu werden unterst tzt das Modellierungs werkzeug Profiles Im ArcStyler enth lt ein Profile folgende Elemente e Stereotype k nnen zu jedem passenden Modellelement hinzugef gt werden e Datentypen k nnen zu jedem TypedElement z B Attribute angegeben wer den e Markierungen sind Schl sselwort Wert Paare welche in definierten Mengen gruppiert vorliegen und mit Standardwerten ausgest
76. dellierungswerkzeug Magic Draw der Firma No Magic im ArcStyler integriert Die Evaluierung wird anhand der aktuellen Version 4 0 108 des ArcStyler Develo per Edition durchgef hrt Fur die Beschreibung bzw Bewertung des Tools wurden mitgelieferte Beispiele und Dokumentationen IO 03a IO 03b IO 03c herangezo gen Zus tzliche Erfahrungen aus der Fallstudie Terminverwaltung siehe Kapitel 5 Kapitel 4 Evaluierung Seite 88 in der ArcStyler als MDA Werkzeug eingesetzt wird erg nzen d e durchgef hrte Evaluierung ArcStyler MDA Cartridges spezifizieren Transformationen Modellierungstool Erstellung von Modellen MDA Engine Ausf hrung von Transformationen m Modellrepository Management und Speicherung von Modellen Abbildung 4 10 Architektur des ArcStyler nach IO 03c Die interne Struktur des ArcStylers wird durch Abbildung 4 10 grob skizziert Die Architektur des Werkzeuges kann nach IO 03a in drei Hauptmodule eingeteilt wer den welche durch den Tool Adapter Standard TAS verbunden sind Die Module und TAS werden im Folgenden genauer beschrieben 4 5 2 Modellierungswerkzeug ArcStyler beinhaltet seit Version 4 0 wie zuvor kurz erwahnt wurde ein integriertes Modellierungstool welches die Modellierung von Diagrammen basierend auf UML 1 4 erm glicht Abbildung 4 11 zeigt die Modellierungsperspektive des ArcStylers wobei auf der linken Seite ein Browser dargestellt wird der die verwendeten Mo
77. der ffentlichen Attribute ber die Konsole ausge geben Package listAttributes OwnedElementClass STGOUL wrate t C lass Name NE PartAttribute lt select Visibility Public STEIOUE WELTS NL Public eerributce Name Wie das Codebeispiel demonstriert bedarf es nat rlich an Wissen uber das n Objec teering UML verwendete Metamodell Im Metamodel User Guide Soft04d wird deshalb eine detaillierte Beschreibung des Metamodells geboten Weitere J Programmbeispiele und eine ausf hrliche Einf hrung in die Sprache J findet man im J Language User Guide Soft04b In Objecteering UML werden uber J Libraries zahlreiche Funktionen wie Sessionmechanismus fur Modelltransformationen Erzeu gung von neuen User Interfaces oder Unterst tzung f r Arbeiten mit dem Dateisys tem geboten Eine ausf hrliche Einf hrung ber angebotene J Libraries erh lt man im J Libraries User Guide Soft04d Der Objecteering UML Profile Builder bietet der BenutzerIn zahlreiche Konzepte die fur die Erstellung von Profiles genutzt werden k nnen Die verf gbaren Konzep te k nnen einerseits in UML standardkonforme Konzepte wie z B Stereotype Schl sselwort Wert Paare und andererseits n von Objecteering UML eigens defi nierte propriet re Konzepte wie z B J Methoden Commands eingeteilt werden Im Folgenden sollen zuerst die UML standardkonformen Konzepte und danach die proprietaren Konzepte aufgelistet und erlautert
78. der Klasse AnmeldeAccessor dienen Die Me thode checkLogin berpr ft durch d e Verwendung der Anmelde Session Bean den eingegebenen Benutzernamen und das eingegebene Passwort auf hre G ltigkeit F r diese Methode ist es notwendig die benutzerdefinierten S gnale des Accessor Aktivitatsdiagramms der Controller Klasse durch spezielle Methodenaufrufe versen den zu k nnen um den im Accessor Aktivitatsdiagramm modellierten Ablauf auf Codeebene zu realisieren Falls die Benutzername Passwort Kombination g ltig ist wird ein ok Signal versendet um in die Benutzerhauptansicht zu gelangen Falls aber die Benutzername Passwort Kombination ungultig ist wird eine entsprechende Feh lermeldung auf der Anmeldeseite angezeigt transition addAction new com io_software catools picasso fsmrt Action authorizieren public void perform com io_software catools picasso fsmrt Event a_Event START OF PROTECTED AREA lt lt 092022a 11009845754 11_534415 2095s insert custom code here try benutzername getAssignmentORepresenter getRoot getBenutzername getFormattedValue password getAssignment ORepresenter getRoot getPassword getFormattedValue bry CalendarAccessor ca CalendarAccessor this ejbCalendarium anmelden Anmeldung al ca getKalendar getSignOn if al authentifizieren ca getBenutzername ca getPassword ca getKalendar setLoggedUserBylId ca getBenutzername
79. der Vorraussetzung dass es sich bei der Datenbank um eine relationale Datenbank handelt Die persistenten Attribute der Entity Bean mussen in einem Deployment Descriptor eingetragen werden o Bean managed Persistence BMP Bei BMP Entity Beans werden Datenbankzugriffe von der Bean selbst ausgefuhrt Die Bean Ent wicklerIn ist somit fur die Persistenz der Entity Bean verantwortlich Ein Vorteil der BMP Entity Beans ist dass Datenbankzugriffe opti miert durchgefuhrt werden konnen Von Nachteil ist naturlich der er h hte Programmieraufwand Session Bean Eine Session Bean ist ein transientes Objekt welches als ser verseitiger Agent Aktionen fur einen Client ausf hrt Es werden generell zwei Typen von Session Beans unterschieden o Stateful Session Bean Eine Stateful Session Bean beinhaltet Informa tionen uber den Status der Kommunikation zwischen Client und Ap plikation Dadurch kann eine Stateful Session Bean immer nur mit e1 nem Client kommunizieren und nicht mit mehreren Clients gleichzei tig o Stateless Session Bean Eine Stateless Session Bean beinhaltet keine Statusinformationen zwischen verschiedenen Aufrufen unterst tzt aber mehrere Clients gleichzeitig Somit kann durch den Einsatz von Stateless Session Beans eine bessere Skalierbarkeit der Applikationen erreicht werden Message driven Bean Message driven Beans sind in Bezug auf die Ausf h rung von Aktionen vergleichbar mit Session Beans Der Unterschied
80. die Aktionen eines Ob jektes beschreiben zu k nnen Dies erfordert den Einsatz einer Action Semantic Lan guage Die bekanntesten Tools im Executable UML Sektor sind mit einer eigenen propriet ren Action Semantic Language ausgestattet Die Tabelle 3 2 listet die be kanntesten Executable UML Toolhersteller und hre Tools auf Toolhersteller Produkt Language ASL Technology Point guage OAL chnology com Kabira Techno Kabira Design Kabira Action Se http www kabira com logies Center mantics Kabira AS Pathfinder Solu PathMATE PathMATE s Action http www pathfindermd tions Language PAL a com Tabelle 3 2 Executable UML Tools Fur die Toolevaluation in Kapitel 4 werden fur den Bereich Executable UML die Tools IUML ICCG und Nucleus BridgePoint genauer betrachtet Das Tool Kapitel 3 MDA Werkzeuge Seite 59 IUML ACCG wurde schon f r eine Vielzahl von Projekten im Embedded Systems Bereich eingesetzt und die Firma Kennedy Carter ist intensiv an der Entwicklung von UML und der Integration von Action Semantics beteiligt Nucleus BridgePoint wird deshalb genauer betrachtet weil Mellor und Balcer die Hauptinitiatoren von Executable UML bei Accelerated Technology besch ftigt sind und so das Tool die Konzepte der Executable UML wohl am vollst ndigsten realisieren wird 3 3 2 Technologiespezifische Werkzeuge Einige MDA Werkzeuge sind auf eine spezifische Technologie ausgerichtet wof r sie besondere Funktion
81. die Ent wicklung von plattformspezifischen Modellen oder die Markierung von plattformu nabhangigen Modellen zu erm glichen Daher sollten Datentypen Stereotype und Schl sselwort Wert Paare f r die aktuellsten Plattformen in den Tools verf gbar sein M11 Unterst tzung von Action Semantic F r Zustands und Aktivit tsdiagramme s nd d e Notationen von Aktionen besonders interessant um das Verhalten pr ziser zu spezifizieren und so durch S mulationen zu berpr fen UML 1 4 besitzt keine Aktionen somit reduzieren sich die S mulat onsm glichkeiten da keine konkreten Aktionen beobachtbar s nd MDA Tools sollten daher die M glichkeit bieten Aktionen zu Zustands und Aktivi tatsdiagrammen beizuf gen um Simulationen und umfangreichere Codegenerierung zu erm glichen Da f r Action Semantics keine standardisierte Sprache existiert muss in der Praxis auf eine der vielen Sprachvarianten ASL KC01 oder OAL Kapitel 3 MDA Werkzeuge Seite 46 AT04 zur ckgegriffen werden Nat rlich w re eine automatische Syntaxuberpru fung zweckm ig um keine fehlerhaften Modellspezifikationen auf Codeebene zu bertragen M12 Anforderungsanalyse Definition und Management von Anforderungen wie z B Nummerierung der An wendungsf lle Versionierung der Anwendungsf lle oder Dokumentation sollten von MDA Tools angeboten werden Eine weitere wichtige Funktion stellt die Tra ceability von Modellelementen auch auf Codeebene
82. die Modellspeicherung wird XML Metadata Interchange XMI OMG02b als Plattform verwendet Durch XMI k nnen XML Schemata und DTDs von MOF basierenden Metamodellen abgeleitet werden und weiters Instanzen von MOF basierenden Metamodellen als XML Dokumente exportiert bzw gespeichert werden Die aufgelisteten Plattformen spezifizieren keine abgeschlossene Menge Kapitel 2 Model Driven Architecture Seite 19 von Zieltechnologien der MDA sondern zeigen nur haufig genutzte Beispieltechno logien Nat rlich liegen ltere Technologien wie z B COBOL oder FORTRAN genauso 1m Fokus der modellgetriebenen Entwicklung wie neu entstehende Techno logien Der auBere Ring beinhaltet sogenannte unterstutzende Services Pervasive Services Diese Services sind grundlegende Dienste die in einem PIM eingearbeitet werden und danach durch Transformationen in beliebige Implementierungen realisiert wer den F r verteilte Systeme sind vor allem unterst tzende Services in den Bereichen Sicherheit Transaktionen und Persistenz relevant Die OMG arbeitet intern an der Erstellung von PIMs f r CORBAservices um diese Dienste plattformneutral zur Verf gung zu stellen Die Vektoren am Rand der Abbildung 2 1 geben einen berblick ber die verschie denen M rkte und Dom nen die vermutlich einen gro en Nutzen aus den modellge triebenen Entwicklungen ziehen werden 2 2 Modelle und Metamodelle Modelle s nd das Schlagwort von MDA Um die unterschied
83. dung soll anhand des MVC Musters entworfen werden Im Folgenden werden Enterprise Java Beans n her erl utert Enterprise Java Beans EJBs sind serverseitige Softwarekomponenten die in einer verteilten und mehr schichtigen Umgebung genannt EJB Container ablaufen Eine EJB kann aus einem Java Objekt oder aus mehreren Java Objekten bestehen da eine Komponente eine gr ere Einheit als ein einzelnes Objekt darstellt Unabh ngig davon wie eine EJB aufgebaut st kann em Client ber eine einzige Komponentenschnittstelle mit der EJB kommunizieren Diese Schnittstelle sowie die EJB selbst m ssen mit der EJB Spezifikation SUNO3b bereinstimmen Die EJB Spezifikation verlangt dass EJBs vorgeschriebene Methoden implementieren Diese vorgeschriebenen Methoden er lauben den EJB Containern alle EJBs gleich zu verwalten Die EJB Spezifikation in der Version 2 0 definiert drei unterschiedliche Typen von Enterprise Java Beans e Entity Bean Eine Entity Bean repr sentiert eine persistente Entitat die in e1 ner relationalen Datenbank gespeichert wird Uber Entity Beans ist es m g lich die persistenten Daten die n einer Datenbank gespeichert vorliegen abzufragen oder zu manipulieren Es k nnen generell zwei Typen von Entity Beans unterschieden werden Kapitel 5 Fallstudie Seite 113 o Container managed Persistence CMP Bei diesem Entity Bean Typ k mmert sich der EJB Container um notwendige Datenbankkommu nikationen unter
84. durch Backslashes entwertet werden m ssen Sobald Skripte zum Gro teil aus Skeleton Code bestehen erm glicht Escaped TPL eine einfachere Erstellung und eine besse re Lesbarkeit des Skriptes Optimal ist mit Editoren f r TPL und Java ausgestattet die Syntax Highlighting Codevervollst ndigung und viele weitere Features unterst tzen Der TPL Editor vi sualisiert die vom TPL Compiler gemeldeten Fehler um der AchritektIn die Fehler suche zu erleichtern Wird ein TPL Skript erfolgreich kompiliert so kann die er zeugte Java Klasse im Java Editor angesehen und sogar ver ndert werden Letztge nanntes sollte aber nur in Ausnahmef llen praktiziert werden da diese nderungen im TPL Skript nicht ber cksichtigt werden und bei der n chsten Kompilierung des TPL Skriptes verloren gehen 4 4 AndroMDA Hersteller Matthias Bohlen und das AndroMDA Team Open Source Projekt Webseite http www andromda org Testversion AndroMDA 3 0M2 4 4 1 Einfuhrung AndroMDA beschreibt sich selbst als ein Open Source Codegenerierungsframework welches auf Konzepten und Prinzipien von MDA basiert Das Tool ist kostenlos ber Kapitel 4 Evaluierung Seite 80 das Open Source Portal SourceForge net beziehbar AndroMDA entwickelte sich aus dem UML2EJB Projekt dessen prim re Aufgabe darin bestand den hohen Schreibaufwand von Infrastrukturcode bei der Entwicklung von Enterprise Java Beans zu reduzieren Dies wurde wie der Name UML2EJB schon ver
85. eicherSelektion wa E HEI Assiopnment root anlegen i IRE g ssEmbedded Accessor gt vg S EintragHinzufuegen SUB final state l s m e s Li lt lt Embecdded Accessor gt gt EintragAendern Abbildung 5 8 Aktivitatsdiagramm f r die Accessor Klasse Hauptseite Modellierung der physischen Komponenten Da die logische Struktur der Terminverwaltung besprochen wurde wird nun mit der Modellierung der physischen Verteilung der Komponenten fortgefahren F r das EJB Subsystem wird ein EJB Archiv names ejbs welches die modellierten Elemente des EJB Subsystems enth lt erstellt Das EJB Archiv wird sp ter im EJB Container eingesetzt Das EJB Archiv wird in einem Komponentendiagramm als Komponente mit dem Stereotyp EJBArchive modelliert F r das Web Subsystem wird ein Web applikationsarchiv ben tigt das sp ter im Webserver eingesetzt wird Dieses Web applikationsarchiv wird als Komponente mit dem Namen webapp und mit dem Ste reotyp Webapplication modelliert Der Stereotyp Webapplication verlangt die Angabe eines RootAccessors der die Startseite der Webapplikation reprasentiert Da das Webapplikationsarchiv das EJB Archiv verwendet muss eine Abhangigkeit vom Webapplikationsarchiv zum EJB Archiv eingezeichnet werden Abbildung 5 9 zeigt das Komponentendiagramm f r die Terminverwaltungsapplikation Kapitel 5 Fallstudie Seite 123 webapp lt lt EJBArchive gt gt jg ejbs
86. eit Ver standnis und Modifizierbarkeit von Applikationen verbessert Mit dem Schritt zur graphischen Repr sentation von Software sollen Programme um einiges verstandli cher werden Aus der Psychologie ist bekannt dass Menschen nur bis zu sieben Dinge gleichzeitig wahrnehmen k nnen Deshalb ist es notwendig mit wenigen Symbolen sehr viel an Information zu vermitteln Um dies zu verdeutlichen wird anschlie end ein kleiner Ausschnitt eines Webshopsystems zuerst n Java siehe nachfolgenden Code als Beispiel f r Hochsprachen und danach als UML Modell Abbildung 1 3 repr sen tiert Durch dieses Beispiel sieht man sehr gut dass die Repr sentationsform durch Modelle f r den Menschen verst ndlicher wirkt als durch textbasierte Beschreibun gen package webshop public class Kunde private int kundenNr private java lang String vorname private java lang String nachname protected java util Collection dieBestellungen new java util Vector public Kunde int kundenNr java lang String vorname ja va lang String nachname this kundenNr kundenNr this vorname vorname this nachname nachname Kapitel 1 Einleitung Seite 6 package webshop public class Bestellung private int bestellNr private java util Date bestellDatum protected webshop Kunde derKunde public Bestellung int bestellNr java util Date bestellDatum this bestellNr bestellNr this bestellDatum bestellDatun webshop Best
87. eits beziehung verbunden Abbildung 5 7 zeigt das Klassendiagramm f r die View und Controllerschicht der Anmeldung eines Benutzers Die Klasse AnmeldenRep enthalt alle Informationen ber die Benutzerschnittstelle und die Klasse AnmeldenAcc ist fur die Steuerung der Anmeldung verantwortlich Die Variablen in der View Schicht mussen auch in der Controller Schicht vorhanden sein um die automatische Weiter gabe der durch den Benutzer eingegebenen Werte in die Controller Klassen zu ge wahrleisten da diese Benutzereingaben erst in der Controller Schicht verarbeitet bzw berpr ft werden Dies wird durch Resource Mappings realisiert die in Zu standsdiagrammen definiert werden k nnen Dabei wird eine Variable A einer Klas se Al als Quelle und eine Variable B einer Klasse B1 als Ziel definiert Vorrausset zung A und B m ssen kompatible Datentypen haben Wird nun der Wert x der Va riable A zugewiesen wird der Wert x durch das definierte Resource Mapping auto matisch der Variablen B zugewiesen Dabei sei wieder darauf hingewiesen dass es sich bei Resource Mappings um propriet re Konzepte des ArcStyler Werkzeuges handelt lt lt AccesSsor gt gt lt lt Representer AnmeldenAcc AnmeldenRep benutzername String kalendar Kalendar 1 message String password String henutzername String message String password String Abbildung 5 7 Accessor Diagramm f r die Anmeldung eines Benutzers
88. eler Tools Solange Profiles nicht in Form von Modulen fur spezielle Domanen ausgewahlt wur den stellt das Tool einen gewohnlichen UML Modellierungseditor dar der aber nicht nur die Syntax aller UML 1 4 Diagrammarten sondern auch die Semantik unterst tzt Somit k nnen erstellte Modelle auf ihre Konsistenz berpr ft werden Werden aber Module f r ein Projekt ausgew hlt so stehen zus tzlich spezifische UML Modellerweiterungen Artefaktgenerierung Modelltransformationen und vie les mehr zur Verf gung Damit diese Funktionen realisierbar sind stehen folgende Konzepte zur Verf gung um den Objecteering UML Modeler zu erweitern e Stereotype Durch die ausgew hlten Module werden Stereotype die in den Profiles der Module enthalten sind nutzbar Zu den modellierten Elementen k nnen diese Stereotype hinzugef gt werden um spezifischere Informatio nen in das Modell einzubringen Zu beachten ist dass nur passende Stereotype einem Modellelement zuge Kapitel 4 Evaluierung Seite 96 wiesen werden k nnen d h die Metaklasse des Modellelementes muss mit der Basisklasse des Stereotyps bereinstimmen oder eine Spezialisierung der Basisklasse des Stereotypen darstellen Visualisiert werden Stereotype im Objecteering UML Modeler entweder durch die ubliche Stereotypnotation mit franz sischen Anf hrungszeichen oder durch zugewiesene Icons Als Beispiel f r Stereotype k nnte das Stereotyp Entity Bean der Plattform En terpr
89. ell plattformabh ngiges Modell Modelltransformationen und Metamodel lierung werden ausf hrlich erkl rt und diskutiert Dabei werden einerseits Probleme der Transformation der verschiedenen Modelle vom Business Modell bis hin zum Code aufgezeigt sowie die Auswirkungen auf den Softwareentwicklungsprozess untersucht Weiters wird auf die manuelle Erstellung von Transformationsregeln eingegangen Anhand eines Kriterienkatalogs werden die Anforderungen an MDA Werkzeuge diskutiert und existierende Werkzeuge untersucht Weiters wird anhand des CALENDARIUMS ein Beispiel MDA Projekt auf Bas s einer relationalen Daten bank Servlets JSPs und EJBs durchgef hrt Dabe wird mit Hilfe von Tools die Er stellung eines lauffahigen Programms aus einem plattformunabh ngigen Modell durchgef hrt Inwieweit die MDA Werkzeuge diese Aufgabe automatisch erledigen k nnen oder an welchen Stellen die ProgrammiererIn selber noch Hand anlegen muss wird durch dieses Beispielprojekt dargestellt Weiters w rd durch d e Tool Evaluierung der ak tuelle Stand der Technik von MDA Werkzeugen aufgezeigt Dabei werden einerseits Bereiche von MDA identifiziert die durch aktuelle Werkzeuge bereits umgesetzt wurden und andererseits aufgezeigt welche Bereiche unzureichend abgedeckt wer den und noch weitere Forschungsaktivit ten ben tigen Abstract Model Driven Architecture MDA s strongly propagated by the Object Manage ment Group OMG and is being introd
90. elle Produkte AndroMDA Unterkapitel 4 4 als Open Source Produkt ausgew hlt F r jedes Werkzeug wird auf die wichtigsten Funktionen wie Modellerstellung Transformationen und hre technischen Realisierungen m Werkzeug n her einge gangen und danach eine Evaluierung des Tools anhand der in Kapitel 3 2 aufgestell ten Kriterien vorgenommen Abschlie end wird m Unterkapitel 4 7 eine bersichtliche Bewertung der bespro chenen Tools anhand des aufgestellten Kriterienkataloges n Tabellenform durchge f hrt Die tabellarische Bewertung soll einen Vergleich der aktuellen MDA Werkzeuge auf einen Blick erm glichen Kapitel 4 Evaluierung Seite 64 4 1 Nucleus BridgePoint Hersteller Accelerated Technology Embedded Systems Division of Mentor Graphics Corporation Webseite http www acceleratedtechnology com Version Nucleus BridgePoint Development Suite 6 1 Windows Edition Nucleus BridgePoint Development Suite im Weiteren kurz mit Nucleus BridgePoint bezeichnet wird von der Embedded Systems Abteilung genannt Accelerated Tech nology der Firma Mentor Graphics Corporation entwickelt Die Umgebung findet seine Anwendung in den Gebieten Echtzeitsysteme Embedded Systems und Simula tionssoftware Nucleus BridgePoint wurde bereits f r die Entwicklung von zahlrei chen Systemen in den Bereichen Flugzeugsteuerung medizinische Systeme und Te lekommunikation erfolgreich eingesetzt Es werden Versionen fur Windows 98 2000 ME
91. ellt Damit die ma nuellen Erg nzungen im Code bei der n chsten Modell zu Code Transformation nicht verloren gehen bietet ArcStyler sogannte gesch tzte Bereiche 1m generierten Code Diese gesch tzten Bereiche werden durch den Codegenerator nicht ber schrieben Im EJB Subsystem stellen die ersten Codeerg nzungsschritte die Vervollst ndigung der benutzerdefinierten create Methoden von Entity Beans dar Da in den meisten Fallen in den create Methoden nur die ubergebenen Parameter den Attributen der Entity Bean mittels Set Methodenaufrufen zugewiesen werden sind diese Erganzun gen rasch und ohne intellektuellen Aufwand durchzuf hren Die Implementierung der Gesch ftslogikmethoden von den Session Beans ist hinge gen um einiges aufw ndiger denn f r die Geschaftslogikmethoden werden nur die Kapitel 5 Fallstudie Seite 130 Methodenr mpfe automatisch generiert die restliche Implementierung bleibt der Programmierln berlassen Als Beispiel f r die Implementierung von Geschaftslogikmethoden wird die Metho de authentifizieren der AnmeldeBean angef hrt Die Methode authentifizieren hat die Aufgabe die berpr fung von Benutzername Passwortkombinationen vorzu nehmen Der daf r verantwortliche Code wird in den gesch tzten Bereich der Me thode authentifizieren von Hand eingetragen Dieses Codebeispiel verdeutlicht dass bei der Implementierung der Gesch ftslogik sehr wohl Kenntnisse ber den generier ten Code und der Soft
92. ellt werden Sobald die ben tigten Cartridges vor handen sind wird mit der Erstellung der UML Diagramme in einem externen UML Tool begonnen Die fertigen Diagramme werden mit Cartridge konformen Stereoty pe und Schl sselwort Wert Paaren verfeinert und danach in eine XMI Date expor tiert bzw gespeichert Nun kommt AndroMDA zum Einsatz welches ber ein ANT Skript oder Maven Plugin aufgerufen wird AndroMDA liest mit Hilfe von MDR die XMI Date und erstellt ein Objektmodell der Diagramme Velocity greift auf das Objektmodell zu und kann mittels definierter Schablonen einen ersten Codeentwurf der Metadaten enth lt erzeugen XDoclet analysiert die von Velocity generierten Ausgabedateien und erzeugt daraus weitere Dateien wie z B Schnittstellenspezifi kationen und Deployment Descriptors Somit ist der gesamte Infrastrukturcode er zeugt und es m ssen nur mehr die Gesch ftslogikmethoden manuell ausprogram miert werden AndroMDA Velocity XDoclet Modell erstellen Modell Objekt Code markieren modell Metatags XMI Code einlesen generieren S erg nzen Infrastruk turcode Abbildung 4 9 Ablauf eines Entwicklungsprozesses mit AndroMDA Kapitel 4 Evaluierung Seite 87 4 5 ArcStyler Hersteller Interactive Objects Software GmbH Webseite http www arcstyler de Testversion ArcStyler Developer Edition 4 0 108 4 5 1 Einf hrung ArcStyler ist eine Softwareentwicklungsplattform die die automatisierte Generie
93. ellung bestellDatum Date bestellNr int kundenNr int nachname String derKunde dieBestellungen vorname String Abbildung 1 3 Webshop Klassendiagramm Code zu stark mit Infrastruktur verflochten Die Spezifikation von Dom nen wie z B Bestellungssystem oder Lagerverwaltung ist auf Codeebene stark mit der Infrastruktur der Softwareplattformen wie z B Pro grammiersprachen Datenbankzugriffe oder Betriebssystemdienste vermischt Da durch ergibt sich folgendes Problem Die Dom nen bleiben uber einen l ngeren Zeit raum konstant hingegen sind Informationstechnologien eher kurzlebig und werden von performanteren Technologien abgel st Ein Umstieg auf neue Technologien ist mit hohen Kosten verbunden da das Dom nenwissen wie z B Geschaftsprozesse zu sehr mit den technischen Details der Softwareplattformen vermischt st wodurch das Dom nenwissen schwer reproduzier bzw f r die neuen Technologien nicht wiederverwendbar ist Fur diese Problematik versucht die OMG mit MDA einen Losungsweg anzubieten Mit der Unterscheidung von plattformunabhangigen und plattformspezifischen Mo dellen ist es m gl ch das Fachwissen ber die Dom ne von den technischen Details der Plattformen bzw von den Programmiersprachen zu trennen In plattformunab Kapitel 1 Einleitung Seite 7 hangigen Modellen werden Gesch ftsprozesse und Dom nenwissen modelliert ohne auf technische Details wie Programmiersprache Softwareplattform Ha
94. en Details im PIM vorkommen kann dieses auf verschiedenen Plattformen rea lisiert werden und ist somit resistent gegen Technologiever nderungen Platform Model PM Um den Begriff Plattformmodell beschreiben zu k nnen muss zuerst der Begriff Plattform erkl rt werden In OMG03a wird eine Plattform als Menge von Techno logien beschrieben die Funktionalit ten durch Schnittstellen und Verwendungsmus ter festlegt Basiert eine Applikation auf einer Plattform kann die Applikation auf die gesamte Funktionalit t der Plattform zur ckgreifen ohne auf die Details der Realisierung der Funktionalit t der Plattform eingehen zu m ssen Grunds tzlich k nnen Plattformen grob in drei Gruppen eingeteilt werden e Generische Plattformen Als Beispiele k nnen Objekte oder Komponenten angegeben werden Eine Plattform ist eine generische Objektplattform wenn sie Konzepte wie Objekte Vererbung und Schnittstellen anbietet e Technologische Plattformen Als Beispiele sind CORBA als Plattform f r verteilte und m glicherweise heterogene Systeme und Java 2 Enterprise Edi tion als Plattform f r komponentenorientierte Softwareentwicklung zu nen nen e Herstellerspezifische Plattformen Diese Plattformen basieren nicht auf all gemeinen Industriestandards haben sich jedoch durch starke Verbreitung und h ufige Nutzung etabliert Beispiele hierf r sind BEA WebLogic Server und Microsofts NET Kapitel 2 Model Driven Architecture Seite 28
95. en Teile und die Sicherstellung dass nur geanderte Dateien neu erstellt werden 4 5 4 Modellrepository Die erstellten Modelle werden entweder als XMI bas erte Textdateien oder in einer verteilten und mehrbenutzerfahigen Modelldatenbank archiviert MDA Cartridges brauchen Zugriff auf die Modellelemente um ihre Aufgaben wie Transformationen und Verifikationen zu erf llen Deshalb ist das Modellrepository ber das Java Me tadata Interface JMD Sun02 und wegen Abw rtskompatibilit t f r ltere Trans l http www mda at work com Stand 12 11 2004 Kapitel 4 Evaluierung Seite 92 formationen ber die C MOD API zug nglich ArcStyler verwendet ab der Version 4 0 UML 1 4 als Metamodell doch wegen Abwartskompatibilitat wird weiterhin das propriet re C MOD Metamodell unterst tzt Letztgenanntes w rd ab der ArcStyler Version 4 0 durch em UML Profile definiert um die Erstellung von C MOD basierenden Modellen mit dem integrierten UML Modellierungswerkzeug zu be werkstelligen Im ArcStyler ist es nicht m glich neue Metamodelle zu definieren es k nnen aber neue UML Profiles durch einen internen Profile Editor erstellt werden Es sei aber darauf hingewiesen dass die fehlende Metamodellerstellungsfunktion nicht durch die Definitionsm glichkeit von UML Profiles ersetzt werden kann 4 5 5 Tool Adapter Standard Verbunden werden die drei Hauptmodule durch den ArcStyler Tool Adapter Stan dard TAS Laut IO 03a kann TAS a
96. en Tools am MDA Marktsektor angeboten jedoch unterscheidet sich der Funktionsumfang der Tools stark vonein ander Um trotzdem einen guten berblick geben zu k nnen werden in diesem Ab schnitt die angebotenen MDA Werkzeuge in vier Kategorien eingeteilt Executable UML Tools technologiespezifische Tools eigentliche MDA Tools und Codegenera toren Executable UML Tools existieren schon seit einigen Jahren und wurden schon Ofters in der Industrie erfolgreich eingesetzt Die Tools versuchen die Konzepte der Exe cutable UML fur die Entwicklung von Software zu implementieren Nahere Informa tionen ber Executable UML werden im Unterkapitel 3 3 1 gegeben Technologiespezifische Tools siehe Unterkapitel 3 3 2 erm glichen die Entwick lung von Softwaresystemen durch den Einsatz von MDA Konzepten Werkzeuge dieser Kategorie unterst tzen aber nur eine bestimmte Plattform wie J2EE und NET Eigentliche MDA Tools siehe Unterkapitel 3 3 3 implementieren einen Gro teil der von MDA geforderten Konzepte und sind auch nicht auf bestimmte Technologien beschr nkt Weiters k nnen diese Tools durch ArchitektInnen f r jegliche Plattfor men erweitert werden Herk mmliche Codegeneratoren siehe Unterkapitel 3 3 4 d rfen nicht mit MDA Tools verwechselt werden da diese meistens keine MDA Konzepte implementieren Werkzeuge dieser Kategorie sind nur auf die Produktion von Skeleton Code spezia lisiert und auch nicht erweiterbar Im Folgenden werde
97. en bereitgestellt Schlie lich kann ein Testclient mittels ANT Skript gestartet werden um die Funkti onalitat der EJB Applikation zu testen Verteilung und Test der Webapplikation Mit dem run ANT Befehl werden alle Java Klassen und JSPs kompiliert Weiters wird eine WAR Datei erstellt der Tomcatserver gestartet und die Webapplikation im Tomcatserver verteilt Danach wird der Standardbrowser gestartet der die Startseite der Webapplikation anzeigt Somit kann auch die Webapplikation vom ArcStyler aus rasch verteilt und getestet werden 5 4 Resumee der Fallstudie Dieses Unterkapitel beschaftigt sich mit den Erfahrungen der Fallstudie Terminver waltung Dabei wird speziell auf die Unterstutzung des MDA Werkzeugs ArcStyler fur die Entwicklung der Terminverwaltung eingegangen Kapitel 5 Fallstudie Seite 134 Das MDA Werkzeug ArcStyler generierte zwar den Gro teil des Codes der Termin verwaltungsanwendung doch die Implementierung der Gesch ftslogikmethoden musste von Hand durchgef hrt werden Das Hinzuf gen der Gesch ftslogik stellte s ch als u erst aufwendig heraus und setzte Kenntnisse ber den generierten Code voraus Als ein Hauptproblem stellte sich die fehlende Spezifikationsm glichkeit von Aktionen auf Modellebene heraus Deshalb konnten die Methodeninhalte erst auf Codeebene und nicht schon auf Modellebene definiert werden ArcStyler bietet zwar die M glichkeit aus den erstellten Modellen Code f r die NET Platt
98. en des UML Metamodells erm glicht Die Unterscheidung zwischen Modellimport export und Codegenerierung durch Transformationen ist in den meisten Tools nicht immer transparent Dennoch w rde eine Modelltransformation nach XMI mehr Flexibilit t mit sich bringen denn da durch w rde die Modifikation des XMI Formats durch die AnwenderIn erlaubt Da oft unterschiedliche Dialekte von XMI n Modellierungstools eingesetzt werden w rde dieses Feature der BenutzerIn die M glichkeit bieten die unterschiedlichen XMI Formate abzugleichen Um die Wiederverwendung von vorhandenen Modellen zu erh hen sollte der Im port Export von einzelnen Modellteilen unterst tzt werden Meistens wird nicht ein komplettes Modell wiederverwendet sondern nur ein bestimmter Ausschnitt Ein Tool sollte z B den Import Export von einzelnen Packages oder Komponenten er l www eclipse org Stand 1 1 2005 2 www netbeans org Stand 1 1 2005 Kapitel 3 MDA Werkzeuge Seite 52 m glichen Daf r ist aber die Grundvoraussetzung dass Modelle in mehrere Berei che Dom nen unterteilt werden und keine monolithischen Modelle erstellt werden 12 Erweiterung In Zukunft werden kontinuierlich neue Anforderungen an MDA Tools hinzukom men Darum sollte em Tool weitere Komponenten aufnehmen k nnen um auf neue Entwicklungen reagieren zu k nnen Zumindest sollten neue Modellierungstools integrierbar sein um bei der Erstellung von Modellen auf individuelle Bed rfnisse
99. en f r das Konfigurations und Versionsmanagement und unterst tzt die automatische Generierung von Dokumentationen Sobald ein Modell im Model Builder erstellt und auf syntaktische Korrektheit ber pr ft wurde kann dieses Modell 1m Model Verifier verwendet werden Der Model Verifier wird f r die interaktive Ausf hrung und Verifikation von durch den Model Builder erstellten Modelle eingesetzt Die Ausf hrung auf Modellebene erm glicht eine fr he Fehlererkennung im Softwareentwicklungsprozess Der Model Verifier erlaubt den EntwicklerInnen die Definition und Ausf hrung von einfachen Unit Tests bus hin zu umfangreichen Testsuiten Abbildung 4 3 zeigt das Hauptfenster des Model Verifiers Zu Beginn muss ein erstelltes Modell ausgew hlt werden Danach muss der Anfangszustand des Systems erstellt werden d h es m ssen die In tialwer te Instanzen von Klassen und Ereignissen erzeugt werden Sind die Initialwerte fur die Simulation definiert kann das System auf drei unterschiedlichen Ausf h rungsgeschwindigkeiten ausgefthrt werden Durch Run wird das System in einem Schritt durchlaufen ohne auf Benutzereingaben oder Zeitereignisse zu warten Mit tels Jog wird pro Zeiteinheit diese Zeiteinheit kann von der Benutzerln frei defi niert werden nur ein Ereignis ausgelost Mit der Einstellung Step steuert die Benut zerIn die Ausfuhrungsgeschwindigkeit Es wird immer nur ein Ereignis ausgel st Kapitel 4 Evaluierung Seite 67
100. er Auswahl des EJB Subsystems 1m Modell browser und der Aktivierung des Befehls Generate ausgef hrt Im Log Fenster des ArcStylers werden alle generierten Artefakte mit hren Systempfaden mitprotokol bert ArcStyler leitet aus einem ComponentSegment folgende Artefakte ab e Remote Interface optional e Local Interface optional e Remote Home Interface optional e Local Home Interface optional e Bean Implementierungsklasse notwendig e Deployment Descriptor notwendig e Prim rschl sselklassen werden nur f r Container managed Persistence En tity Beans generiert Als Beispiel f r die generierten Artefakte des EJB Subsystems wird folgendes Code segment aus der Datei AnmeldungBean angegeben F r Bean Implementierungsklas sen werden einerseits vorgeschriebene Methoden f r den EJB Container wie z B die Methode ejbActivate und andererseits Methodenr mpfe mit gesch tzten Be reichen f r selbstdefinierte Methoden wie z B die Methode authentifizieren durch die WLS Cartridge erzeugt package ejbCalendarium anmelden public class AnmeldungBean implements javax ejb SessionBean public void ejbCreate throws CreateException public void ejbActivate public boolean authentifizieren java lang String benutzer java lang String password START OF PROTECTED AREA lt lt authentifizieren SSE RING St Lingen 9 insert custom code here END OF PROTECTED AREA 1604e74e0000006e C Kapitel 5
101. eriert werden k nnen EJB generiert Container Managed Persistent Entity Beans und Session Beans Hibernate Java Spring WebService XmiSchema Tabelle 4 2 MDA Cartridges des AndroMDA Frameworks F r jede MDA Cartridge gibt es eine vordefinierte Menge von Stereotypen und Schl sselwort Wert Paaren die f r die Steuerung der Codegenerierung unbedingt ben tigt werden In Tabelle 4 3 wird f r die E B Cartridge ein kurzer Auszug aus den vorhandenen Stereotypen angegeben Stereotype Modellelement Beschreibung Classifier wird als CMP Entity Bean abgebildet Classifier wird als Session Bean abgebildet FinderMethod Operation wird als Finder Methode abgebildet Tabelle 4 3 Auszug aus dem Stereotypverzeichnis der EJB Cartridge 4 4 5 Ablauf eines Entwicklungsprozesses mit AndroMDA Da die interne Struktur des Frameworks ausreichend beschrieben wurde k nnen nun die Aktivit ten eines Entwicklungsprozesses der AndroMDA als Entwicklungsfra mework verwendet definiert werden Am Beginn jedes Projektes m ssen Cartridges fur die einzusetzenden Technologien Plattformen identifiziert werden Sind entwe der mit AndroMDA mitgelieferte oder selbsterstellte Cartridges welche die identifi z erten Plattformen unterst tzen vorhanden kann sofort mit der Erstellung des Sys Kapitel 4 Evaluierung Seite 86 tems begonnen werden Sollten aber keine Cartr dges f r d e Plattformen vorhanden sein m ssen neue Cartridges erst
102. erlautert Weiters wird ein Grundmechanismus der MDA namlich die Modelltransformationen besprochen AbschlieBend wird das Zusammenspiel der Modellarten und der Transformationen anhand eines kleinen Beispieles skizziert Computation Independent Model CIM Ein CIM spezifiziert die Anforderungen der zu realisierenden Applikation ohne auf die rechnerunterstutzte Verarbeitung einzugehen Somit ist ein CIM unabhangig von der Realisierung des Systems denn in dieser Phase ist noch nicht geklart ob uber haupt ein Computer zur Informationsverarbeitung eingesetzt wird CIMs haben die Aufgabe ein System mit seiner Umgebung zu beschreiben und sollen ein besseres Verst ndnis der Aufgaben des Systems erm glichen Weiters wird ein CIM auch als Kapitel 2 Model Driven Architecture Seite 27 Dom nenmodell oder Gesch ftsmodell bezeichnet denn es definiert auch ein ge meinsames Vokabular des Problembereiches Als Notationsm glichkeiten k nnen beliebige Flussdiagramme besonders geeignet sind UML2 Aktivit tsdiagramme oder Klassen bzw Anwendungsfalldiagramme eingesetzt werden Platform Independent Model PIM Ein PIM ist ein abstraktes und von jeder Implementierungstechnologie unabh ngiges Modell Im Unterschied zu CIM wird beim PIM auf Computer unterst tzende Verar beitung zur ckgegriffen Somit definiert ein PIM ein Softwaresystem welches die Anforderungen und Funktionalit t des CIM ber cksichtigt Da keine plattformspezi fisch
103. ert wurde Executable UML von Mellor und Balcer in Mell02 Ein Executable UML Modell nutzt vorwiegend Klassendiagramme Zu standsdiagramme und Aktionen Weitere UML Diagramme k nnen zur Verdeutli chung von Systemfunktionalit ten eingesetzt werden Da sie aber keine Ausf h rungssemantik in Executable UML besitzen k nnen sie weder simuliert noch trans formiert werden Anwendungsfalldiagramme und Aktivitatsdiagramme k nnen f r die Anforderungsanalyse eingesetzt werden bevor der eigentliche Systementwurf beginnt Im Folgenden werden die ausf hrbaren Konzepte Klassendiagramm Zu standsdiagramm und Aktion n her erl utert Zus tzlich bietet Tabelle 3 1 eine gro be Zusammenfassung der ausf hrbaren Konzepte e Klassendiagramm Diese Diagrammart wird eingesetzt um die formale Struktur des Systems zu zeigen wobei alle Entit ten des Systems identifi ziert und als Klassen abstrahiert werden Wichtige Eigenschaften der Entita ten werden als Attr bute modelliert und Beziehungen zwischen den Entit ten als Assoziationen Operationen werden nicht explizit in Klassen angegeben da Operationen in Form von Aktionen in Zustandsdiagrammen angegeben werden Ein System sollte in Dom nen unterteilt werden um bersichtlichere Teil systeme zu erhalten wobei ein Teilsystem aus Klassen und ihren Beziehun gen besteht Jede Dom ne wird f r s ch selbst modelliert ohne auf andere Dom nen einzugehen Um Beziehungen zwischen Dom nen zu ber
104. erte Abbildungen nach MDAO03 Kapitel 3 10 1 32 Abbildung 2 10 Instanzbasierte Abbildungen nach MDA03 Kapitel 10 3 3 33 Abbildung 2 11 Musterbasierte Abbildungen nach MDA03 Kapitel 10 3 4 34 Abbildung 3 1 m glicher MIDA Fntwicklungsprozesg 31 Abbildung 4 1 Aufbau der Nucleus BridgePoint Umgebung nach ATO04a 65 Abbildung 4 2 Hauptansicht des Model Bulder 66 Abbildung 4 3 Hauptansicht des Model Verifier cccccccccccceceeeeeeeeeesseeeeeeees 67 Abbildung 4 4 Benutzeroberflache des IUML Simulators 2 cceeeeeeeeeeeeee 69 Abbildung 4 5 1CCG Codegenerierungsframework basierend auf KC04 70 Abbildung 4 6 freie und gesch tzte Codebereiche in Optimal 74 Abbildung 4 7 Abstraktionsebenen und Pattern Kategorien in OptimalJ nach EIN EE 76 Abbildung 4 8 Aufbau des AndroMDA Frameworks 8l Abbildung 4 9 Ablauf eines Entwicklungsprozesses mit AndroMDA 86 Abbildung 4 10 Architektur des ArcStyler nach IO O3ec 88 Abbildung 4 11 Modellierungsperspektive des ArcStylers ccccccccccceeeeeeeeeees 89 Abbildung 4 12 ArcStylers Auswahlmenu fur Markierungen eeneeeeeeeeeeenennsesssns 90 Abbildung 4 13 UML Modeler und UML Profile Builder nach Soft99 94 Abbildung 4 14 Hauptansicht des Objecteering UML Modeler Tools 95 Abbildung
105. erten Metaklassen hinzuzuf gen Wird ein Modell element mit einem Stereotyp f r das Notes verf gbar sind gekennzeichnet so k nnen die dem Stereotypen zugeteilten Notes zu diesem Modellelement angegeben werden Im Objecteering UML Modeler werden Notes mittels der Kommentarnotation aus UML visualisiert In Notes k nnen Textfragmente f r die Generierung von Quelltexten oder Dokumentationen hinterlegt wer den Als Beispiel k nnte einer Methode ein Note vom Typ JavaCode ange f gt werden die den Implementierungscode der Methode enth lt Kapitel 4 Evaluierung Seite 97 e Commands Module k nnen ber Commands verf gen die den Objectee ring UML Modeler durch modulspezifische Popup Men s oder Kontext Men s erweitern Diese Mentipunkte sind mit J Methoden siehe Kapitel 4 6 2 Abschnitt Propriet re Konzepte desselben Moduls verkn pft Das Verhalten der J Methoden wird bei der Auswahl des Men punkts ausgef hrt Durch Commands k nnen z B Codegenerierung Dokumentationsgenerie rung oder die Anzeige von Metriken ber das Modell aufgerufen werden e Work Products Dieses Konzept repr sentiert von Objecteering UML gene rierte Artefakte wie Dokumentationen Codedateien Makefiles usw Durch Work Products ist die Konsistenz zwischen den Modellen und den erzeugten externen Artefakten gegeben Ist f r die Metaklasse eines Modellelementes ein Work Product definiert so wird bei der Markierung dieses Modellele mentes ein Symb
106. etamodel and UML Profile for Java and EJB Specification http www omg org cgi bin apps doc formal 04 02 02 pdf 15 2 2005 2004 Literaturverzeichnis Seite 151 OMG05 Object Management Group UML Profile for Schedulability Perform Rais04 Seli03 Sims04 Soft01 Soft04a Soft04b Soft04c Soft04d Soft04e ance and Time Specification http www omg org cgi bin apps doc formal 05 01 02 pdf 15 2 2005 2005 C Raistrick et al Model Driven Architecture with Executable UML Erste Auflage Cambridge University Press Cambridge 2004 B Selic An Overview of UML 2 0 http www omg org news meetings workshops MDA_2004 Manual 0 3 Tutoriall Selic pdf 12 2 2005 2003 O Sims Enterprise MDA or How Enterprise Systems Will Be Built http www cs kent ac uk projects kmf mdaworkshop submissions Sims p df Stand 15 2 2005 2004 SOFTEAM MDA When a major software industry trend meets our toolset implemented since 1994 http www objecteering com pdf whitepapers us mda pdf 12 2 2005 2001 SOFTEAM Objecteering UML Profile Builder User Guide Version 5 3 http www objecteering com pdf doc us UMLProfileBuilder pdf 12 2 2005 2004 SOFTEAM Objecteering J Language User Guide Version 5 3 http www objecteering com pdf doc us JLanguage pdf 12 2 2005 2004 SOFTEAM Objecteering J Libraries User Guide Version 5 3 http www objecteering com pdf doc us JLibraries pdf 12 2 2005 200
107. existiert Im Informatikbereich k nnte ein Applikationsserver mit einem CD Player verglichen werden und eine Komponente mit einer CD denn jede Komponente l uft in jeden beliebigen Applikationsserver Die Einf hrung von Komponenten l ste viele Probleme der Softwareentwicklung leider brachte s e aber ein neues Problem mit sich Auch Komponenten unterliegen nderungen im Laufe der Zeit Wenn sich nun ein Interface ndert m ssen dadurch weitere Modifikationen 1m Quelltext innerhalb von Komponenten stattfinden Da nach bedarf es an Komponententests und schlie lich an Systemtests Dies k nnte einen Grund daf r darstellen warum Komponenten bei weitem nicht so stark einge setzt wurden als erwartet Durch den Einsatz von Dom nenmodellen wird das Wiederverwendungspotential weiter gesteigert Dom nenmodelle sind Modelle die eine bestimmte Anwendungs Kapitel 1 Einleitung Seite 10 dom ne plattformunabh ngig beschreiben Viele Anwendungsdom nen von Soft ware wie z B Bestell oder Lagerverwaltungssysteme bleiben ber l ngere Zeit konstant Werden f r diese Dom nen plattformunabhangige Modelle entwickelt so kann die Entwicklung von Applikationen stark beschleunigt werden Eine durch plattformunabh ngige Modelle definierte Dom ne kann in mehreren Applikationen eingesetzt werden Ein Dom nenmodell sollte die Struktur und das Verhalten einer Dom ne definieren F r die Strukturmodellierung bieten sich Klassendiagramme an
108. f 1 2 2005 2003 Literaturverzeichnis Seite 150 OMGO3b Object Management Group Unified Modeling Language Specification Version 1 5 http www omg org cgi bin apps doc formal 03 03 O1 pdf 1 2 2005 2003 OMGO3c Object Management Group Common Warehouse Metamodel CWM Specification Version ek http www omg org cgi bin apps doc formal 03 03 02 pdf 1 2 2005 2003 OMGO3d Object Management Group Object Constraint Language OCL Specifi cation Version 1 1 http www omg org cgi bin apps doc ptc 03 10 14 pdf 1 2 2005 2000 OMG03e Object Management Group UML 2 0 Testing Profile Specification http www omg org cgi bin apps doc ptc 03 08 03 pdf 15 2 2005 2003 OMGO3f Object Management Group UML 2 0 Superstructure Specification http www omg org cgi bin apps doc ptc 03 08 02 pdf 15 2 2005 2003 OMG04a Object Management Group UML Profile for Enterprise Distributed Ob ject Computing EDOC http www omg org technology documents formal edoc htm 15 2 2005 2004 OMG04b Object Management Group UML Profile and Interchange Models for Enterprise Application Integration EAT Specification http www omg org cgi bin apps doc formal 04 03 26 pdf 15 2 2005 2004 OMG04c Object Management Group UML Profile for Modeling Quality of Ser vice and Fault Tolerance Characteristics and Mechanisms http www omg org cgi bin apps doc ptc 04 06 01 pdf 15 2 2005 2004 OMG04d Object Management Group M
109. file Builder nennen en a esteee eueessesss 99 AT EVALUERUNG DER WERKZEUGE unsre AE E E EAE O E se ige 107 KAPITELS FALLS TU DED 2030200880 a rasen 110 J l BESCHREIBUNG DER TERMINVERWALTUNG sen un en een 111 522 EINZUSETZENDE TECHNOLOGIEN ariora ei E EN caategeades One eatapantal enseas ies 112 5 3 DURCHEUHRUNG DESPROJERTES ns aan ne E EE A T 115 EE EE 116 II GONT UNE der EE 423 J EFEANZUNE des Senerierten Codes irn 129 EE E 132 3 4 RESUMEE E NEE E EE EE 133 KAPITEL 6 ZUSAMMENFASSUNG UND AUSBLICK 220000000000000000000ssnnnnnnsssnnssssnsnnnsssnnnne 137 GEET 137 EE eer 138 ANHANG A MODELL DER TERMINVERWALTUNG 0000sssssssonsonsssssssnnnssnnsssssssnnsssnnnnnee 141 ANHANG B CODE DER TERMINVERWALTUNG ssssssssssssssssssssnnsssnnsssssssnnsssnnssssnsnsssnnnneee 142 ABBILDUNGSVERZEICHNIS gege 143 TABELLENVERZEICHNIS LITERATURVERZEICHNIS Kapitel 1 Einleitung 1 1 Motivation f r MDA Heutzutage st d e Softwareentwicklung mit mmer gr er und komplexer werden den Systemen konfrontiert man denke an Online Bestellsysteme wie z B Amazon oder an den Einsatz von mobilen Ger ten wie z B PDAs oder Mobiltelefonen Mit objektorientierter Programmierung und verbesserten Softwareentwicklungsprozessen versuchen die SoftwareentwicklerInnen und SoftwarearchitektInnen den hohen Pro grammieraufwand in den Griff zu bekommen Aber dennoch bleibt die Softwareent wicklung trotz Fortschritten noch immer u erst arbei
110. form zu generieren doch die Methoden m ssen in CH neu implementiert werden Generell kann gesagt werden dass Funktionalit t die erst auf Codeebene und nicht schon auf Modellebene definiert wird f r Transformationen des Modells fur Implementierungen welche auf anderen Plattformen basieren nicht genutzt wer den kann und fur diese Implementierungen neu erstellt werden muss Diese Proble matik zeigt einmal mehr dass noch viele Verbesserungen in den MDA Werkzeugen notwendig sind da noch immer viele Arbeitsschritte erst auf Codeebene durchge f hrt werden k nnen Zusammenfassend k nnen folgende positive und negative As pekte der Erstellung der Terminverwaltung durch das MDA Werkzeug ArcStyler angeben werden Positive Aspekte e Der Infrastrukturcode f r EJBs w e z B Schnittstellen oder Deployment Descriptors wird vollst ndig automatisch generiert e Das Datenbankschema f r die Speicherung der persistenten Attribute und Assoziationsrollen der Entity Beans wird vollst ndig aus dem EJB Modell generiert e Die WebAccessors Cartridge erm glicht eine gute Trennung zwischen der View und der Controllerschicht e Da ArcStyler ber eine integrierte Testumgebung verf gt k nnen Prototypen rasch erstellt und getestet werden ohne die ArcStyler Umgebung zu verlas sen Die automatisch generierten Benutzeroberfl chen sind zwar nicht forma tiert stellen aber trotzdem eine gute Black Box Testm glichkeit dar Kapitel 5 Fal
111. fur die Accessor Klasse Startseite wel che die Hauptsteuerung der Terminverwaltung bernimmt Der Representer State Start reprasentiert den oberen und unteren Frame der Benutzeroberflache die Repre senter Klassen der eingebetteten Zust nde werden im mittleren Frame angezeigt Der Representer State Start enth lt einen Representer States Ansicht und vier Em bedded Accessor States Login Logout EintragHinzufuegen und EintragAendern Die Transitionen mit der Beschriftung SUB transitionsnamenl final state werden aktiviert sobald der Endzustand des Zustandsdiagrammes der eingebetteten Acces sor Klasse erreicht wurde Die Trans tionen mit der Beschriftung IREI transitionsnamen schalten sobald eine entsprechende Schaltfl che der Repre senter Klassen aktiviert wurde Kapitel 5 Fallstudie Seite 122 ae i Initialize N i d entry initalize 4 e lt lt Representer State gt gt g j ren Fi we a Start fi IRE oben root login j we wi Se H H H En Ga Embedel once 550 Login i SUB logoutTrue final state d SUBI finaltfinal state be 8 f lt en Bes Se s F vi lt lt Embedded Accessor gt gt BE LogOut SUB encditinal state pe N ISU B final final state N lt lt Representer State gt gt Ansicht entry refresh JRE Assignment root terminListe ltemView delete loescheTermin V RE Assignment rootterminListeitternviewibearbeitenisp
112. genauso wie Sprachen durch ein Modell beschrieben Deshalb wird wieder eine wohldefinierte Sprache ben tigt welche das Modell der Metaspra che definiert Somit w rden sich aber unendlich viele Metamodellierungsschichten auftun da immer wieder eine Sprache zur Beschreibung der obersten Schicht ben Kapitel 2 Model Driven Architecture Seite 24 tigt w rde Dieses Problem wird im Metamodellierungsansatz der OMG dadurch vermieden dass die Metasprache reflexiv d h sich selbst erklarend ist Um diesen Losungsweg zu verdeutlichen soll die Deutsche Sprache als Beispiel dienen Deutsch wird durch Grammatikregeln und einem Wortschatz W rterbuch definiert wobei die Grammatikregeln und die W rter selbst mit Deutsch beschrieben werden Weiters werden Sprachen und Metamodelle bzw Metasprachen und Metametamo delle als selbiges angesehen da die Unterscheidung keinen praktischen Nutzen bringt geschrieben n Metasprache gt Metameta definiert modell durch geschrieben in Meta modell definiert durch geschrieben Abbildung 2 4 Sprachen und Metasprachen Da wir nun das n tige Grundwissen ber Metamodellierung besitzen k nnen wir den Metamodellierungsansatz der OMG genauer begutachten Von der OMG wird MOF als Metamodellierungssprache zur Definition von Metamodellen verwendet Konkrete Instanzen von MOF werden als Modellierungssprachen eingesetzt Abbil dung 2 5 gibt einen
113. gs mit folgender Skala bewertet Kriterium wird vollst ndig umgesetzt O Kriterium wird nur teilweise umgesetzt Kriterium wird nicht umgesetzt 2 Kriterium kann wegen fehlender Informationen nicht bewertet werden Um die Evaluierung bersichtlich darstellen zu k nnen werden folgende Abk rzun gen f r die vorher beschriebenen Werkzeuge eingef hrt NU Nucleus Bridgepoint IU IUML ICCG OP Optimal AN AndroMDA AR ArcStyler OB Objecteering UML Im Folgenden wird je Kriterienkategorie eine Tabelle angegeben um die Ergebnisse der Toolevaluation zusammenzufassen Kapitel 4 Evaluierung Seite 108 Modelierungskrterien NU TU OP AN AR OB MisUnesting ion UMLIa720 ool M2 Erstelng von UML Profiles ols M3 Definition von auf MOF basierenden Meta i modellen PIE LE ES EBEN EN M5 OCL Unterst tzung M6 Modeling ER EERESER M7 Modellsimulation Jill M8 Unterst tzung von Markierungen M9 User Interface Modellierung rg renner rer DE SA D FE ER Unterst tzung von abstrakten konkreten Plattformen ae ut M12 Anforderungsanalye Join 0 0 M13 Modellierung von Testf llen 10 010 M14 Mehrbenutzerf higkeit Jill Tabelle 4 6 Modellierungsanforderungen Modeltranstormationskriterien NU 1U OP AN AR OB T1 Modeltzu Modeli Transformation 12 Modet zu Code Transformation li T3 Traceablitity zwis
114. h BOTL http www4 in tum de marschal pub marschall_ braun mdafa03 pdf Stand 1 2 2005 2003 Matu03 M Matula NetBeans Metadata Repository http mdr netbeans org MDR whitepaper pdf 12 2 2005 2003 Mell02 S J Mellor M J Balcer Executable UML A Foundation for the Model Driven Architecture Erste Auflage Addison Wesley Verlag 2002 Mell04 S Mellor K Scott A Uhl MDA Distilled Addison Wesley Verlag 2004 OMG95 Object Management Group Object Management Architecture Guide http www omg org cgi bin apps doc ab 97 05 05 pdf 1 2 2005 1995 OMG00 Object Management Group UML Profile for CORBA Specification http www omg org cgi bin apps doc ptc 00 10 01 pdf 15 2 2005 2000 OMG01 Object Management Group Model Driven Architecture MDA http www omg org cgi bin apps doc ormsc 01 07 01 pdf 1 2 2005 2001 OMG02a Object Management Group Request for Proposal MOF 2 0 Query Views Transformations RFP http www omg org cgi bin apps do doc ad 02 04 10 pdf 1 2 2005 2002 OMG02b Object Management Group XMLMetadata Interchange XMI Specifi cation http www omg org cgi bin apps doc formal 02 01 01 pdf 1 2 2005 2002 OMG02c Object Management Group Meta Object Facility MOF Specification Version 1 4 http www omg org cgi bin apps doc formal 02 04 03 pdf 1 2 2005 2002 OMG03a Object Management Group MDA Guide Version 1 0 1 http www omg org cgi bin apps doc omg 03 06 01 pd
115. h ftslogik oder Datenbank Metamodell werkzeugintern verarbeitet F r die Definition von Metamodellen wird MOF in der Version 1 4 eingesetzt Mit Hilfe der Architecture Edition k nnen SoftwarearchitektInnen neue auf MOF basierende Metamodelle entwerfen oder die von Compuware bereitgestellten Metamodelle fur ihre individuel len Anforderungen anpassen Durch ein erstelltes Metamodell ist die automatische Generierung der zugeh rigen Repository API m glich wobei das MOF Modell nach Java transformiert wird Die Repository API wird einerseits verwendet um Metamo dellelemente zu erstellen zu verandern oder auf ihre Werte zuzugreifen und anderer seits um die auf dem Metamodell basierenden Modelle zu speichern Die in Opti malJ verwendete Repository API ist mit der Java Metadata Interface Spezifikation zu vergleichen nur wurde die Repository API speziell f r OptimalJ mit zus tzlichen Funktionalit ten ausgestattet Durch die Repository API kann auf Werte von Mo dellelementen zugegriffen werden Dieses Feature wird speziell bei der Erstellung von Transformationen haufig genutzt Kapitel 4 Evaluierung Seite 77 OptimalJ generiert Modelle und Code durch den Einsatz von Transformation Patterns Modelle werden n weitere Modelle durch Technology Patterns transfor miert und der Code wird von Modellen durch Implementation Patterns erzeugt Mit Hilfe der Architecture Edition k nnen neue Technology und Implementation Patterns erstellt und d
116. hen Um den Einsatz der Profiles im Objecteering UML Modeler zu gew hrleisten m ssen diese zuerst zu Modulen gepackt werden Die mit Objecteering UML mitgelieferten Module siehe Tabelle 4 5 wurden mit Objecteering UML Profile Builder erstellt Diese Module und ihre zugeh rigen Pro files k nnen zwar nicht direkt ver ndert werden es k nnen aber neue Profiles von diesen abgeleitet und dadurch diese Profiles f r individuelle Anforderungen erwei tert werden Die Hauptansicht des Objecteering UML Profile Builder die in drei Bereiche ge gliedert ist wird in Abbildung 4 16 dargestellt Der Meta Explorer Nummer 1 in Abbildung 4 16 zeigt eine Baumstruktur die alle Elemente eines Projektes enth lt Der Meta Eigenschaften Editor Nummer 2 in Abbildung 4 16 zeigt die Eigen schaften des aktuell markierten Elementes Die Konsole Nummer 3 in Abbildung 4 16 beinhaltet wie beim Objecteering UML Modeler Tool Feedback fur die Ent wicklerIn Das Hauptfenster Nummer 4 in Abbildung 4 16 wird zum Testen von erstellten Profiles verwendet d h es ist nicht notig in den Objecteering UML Mode ler zu wechseln um die Funktionalitat des gerade erstellten Profile zu testen Kapitel 4 Evaluierung Seite 100 VC Objecteering UML Profile Builder UMLProfilingProject12 File Edit View Graph Tools Test Windows Ta default 7 external a Report Ea test_profile HA Class Rk test_stereo te test_genertemplate Class Clas
117. hererInnen und SoftwarearchitektInnen eingesetzt um UML Profile zu erstellen Diese werden zu Modulen zusammengefasst und im Objecteering UML Modeler verwendet Kapitel 4 Evaluierung Seite 94 UML Modeler UML Profile Builder MM N le CS Softwarede Softwarear signerInnen chitektInnen SS Pr N T Program Qualitatssi miererInnen Module chererInnen Software Modelle Profile Repository Abbildung 4 13 UML Modeler und UML Profile Builder nach Soft99 Die Definition und Verwendung von UML Profiles durch die mitgelieferten Tools von Objecteering UML kann in die folgenden Schritte zusammengefasst werden 1 Erstelle mit Hilfe des Objecteering UML Profile Builder die ben tigten Pro files f r die eingesetzten Plattformen und verpacke diese zu verteilungsfahi gen Modulen 2 Verteile die erstellten Module in Modelldatenbanken 3 Wahle im Objecteering UML Modeler ein oder mehrere Module aus und erstelle damit Softwaremodelle 4 6 2 Objecteering UML Modeler Objecteering UML verf gt ber ein eigenes UML Modellierungstool namens Objec teering UML Modeler Als Modellierungssprache wird bei der vorliegenden Version UML 1 4 verwendet seitens SOFTEAM wird aber eine Umstellung auf UML 2 0 vorbereitet Motiviert ist die Umstellung durch die bessere Unterst tzung der Notati on von UML Profiles in UML 2 0 und durch die Mitgliedschaft von SOFTEAM im UML 2 0 Response Team Soft01 Abbildung 4 14 zeigt die Hauptansicht des O
118. hicht wird eine Exportfunktion fur Macromedia Dreamweaver angeboten um der Benutzerln die Erstellung der Benutzerschnittstelle zu erleichtern Kapitel 4 Evaluierung Seite 74 Zn Da e a AI e e hi lt project mawe package_Froject Ege defeult all basedir gt Ware hikes CRG SE LL de Led Lee F Ti svailable file ddjurerdelinedease walj property enecucelfserdelinedTach F ET property Fae yee hoe valus netbeans eee fe Wi ZprGpertt Tilae r 45 Weer hie SER proj ct DroparEiagr k propre nasa pj home value Ci Compuvere fr property tile Projecchjhbuild properties gt Si iproperty Dags ugrerdeiingdrark rel r lupsruwgerd etit cb ark sl m property pD pger Proieec jbrach values co be overridden gt Wi ZPtGngertg Dame gouugcgabathr T lie Lo Be ouerrttddenp ik iPr apie rey fide ee Lee EPSEA vali ss ES E cite rridaden s F sptopgtte Fame Servlet Jar value 107 home fcomeendoe commons iib serviet Jar Zr tpraperey hina aleuralibCeapile iar valus Floh home flLibbepleyfalturalsbCompile jar dr ir part nase jar rata valuse ES Es Z rrid epPdk properly nimas L C gougc bathn valide EL ME ied rabarlh FP PERRET nana debug value uru pach Ld genarace CLarspach gt pathelement locarione Hialturalibloapile Jar ini Latah ane s er Pe SP LIn Pre peck spn licekian Jar P narcrhelesene lores lene Jjarbaerkj
119. hitecture MDA wird von der Object Management Group OMG stark vorangetrieben und halt Einzug in die Softwareentwicklung MDA wird als nachster Schritt des Formalisierungs und Abstraktionsprozesses von Software gese hen etwa wie die Ablose von Assembler durch Hochsprachen Schenkt man den vielen Versprechungen der OMG Glauben so lassen sich aus technologieunabhang gen Modellen problemlos Anwendungen fur verschiedenste Plattformen wie J2EE CORBA oder NET automatisch generieren Dabei gibt die OMG nur eine theoretische Architektur und Spezifikation von MDA vor die Implementierungen von Werkzeugen bzw Transformationsregeln wird an die Softwareindustrie abgegeben Diese soll in nachster Zeit fur Automatisierungs tools sorgen die die Modelltransformationen und weitere Hilfsmittel fur den erfolg reichen Einsatz von MDA unterst tzen In der Praxis wurden schon mehrere Projekte mittels MDA auf Bas s der bereits vor handenen Werkzeuge verwirklicht Die Vision dabei ist dass Softwareanwendungen automatisch generiert werden Hier ist aber zu kl ren ob die Tools wirklich An spruch auf MDA haben oder ob es sich nur um UML Tools handelt die Codeseg mente automatisch aus grafischen Modellen ableiten k nnen Die Diplomarbeit beschreibt ausf hrlich die theoretischen Konzepte von MDA so wie die praktische Umsetzung von MDA anhand eines Ausschnitts des CALENDARIUM Projektes Die theoretischen Konzepte wie plattformunabh ngi ges Mod
120. hrichten hnlich einem Methodenaufruf n Java und der Diffusionsmecha nismus Mit Hilfe des Diffusionsmechanismus sind Mengen von Modellelementen sehr einfach zu verarbeiten ohne dabei auf den Gebrauch von komplizierten Iterato ren oder for Schleifen zur ckgreifen zu m ssen Wird die Diffusion auf eine nicht leere Elementmenge angewandt so wird f r jedes Element die angegebene Nach richt versendet Wendet man jedoch die Diffusion auf eine leere Menge an wird eine Nulloperation noop ausgef hrt Syntaktisch wird die Diffusion als lt repr sentiert Weiters wird der Diffusionsmechanismus durch zwei spezielle Operatoren unter st tzt Mit Hilfe des select Operators werden bestimmte Elemente aus einer Menge aufgrund eines boolschen Ausdrucks gefiltert Das Ergebnis ist eine Teilmenge in der alle Elemente die Bedingung erf llen Der while Operator wird eingesetzt um eine Menge von Elementen so lange zu durchlaufen bis ein angegebener boolscher Ausdruck nicht mehr erf llt wird Sobald die Bedingung nicht erf llt ist bricht die Verarbeitung der Diffusion ab Kapitel 4 Evaluierung Seite 102 Anonyme Methoden s nd ein Spezialfall der Diffusion und werden als Methoden oh ne Namen und Parameter angeschrieben Es wird zuerst eine Referenz auf eine Ele mentmenge angegeben und darunter ein Programmblock n geschwungenen Klam mern angef gt Bei der Ausf hrung des Programms wird der gesamte Programm block f r jedes einzelne E
121. hrt und hantiert mit Modellelementen welche durch BenutzerInnen des Objecteering UML Modeler erstellt werden In J sind zwei Kapitel 4 Evaluierung Seite 101 Arten von vordefinierten Klassen verf gbar einersteits Klassen f r grundlegende Datentypen wie z B String Float Integer und andererseits solche die Elemente des Metamodells von Objecteering UML reprasentieren wie z B Classifier Attribu te Package Bei der Erstellung von J Programmen werden nur vorhandene Klassen genutzt d h J ProgrammierInnen k nnen entweder neue Methoden f r die vorhandenen Klassen definieren oder vorhandene redefinieren aber k nnen selbst keine neuen Klassen deklarieren J wird also verwendet um Methoden auf Metaklassenebene Instanzen des UML Metamodells zu definieren Wie zuvor besprochen kann mittels J auf das Metamodell von Objecteering UML zugegriffen werden J verwendet Metaklassen Metaassoziationen Metarollen und Metaattribute um durch em Modell navigieren zu k nnen und damit die ben tigten Modellinformationen zu bekommen Die Sprache J baut sehr stark auf das Konzept Nachrichten auf In Objectee ring UML wird eine Nachricht allgemein als Aufruf der ein m gliches Ergebnis liefert definiert Meistens beschr nkt sich aber eine Nachricht auf die Abfrage eines Attr butwertes oder den Aufruf einer J Methode Um Nachrichten n J effizient zu nutzen werden zwei Hauptkontrollkonstrukte angeboten n mlich das Versenden von Nac
122. ibute automatisch angezeigt und sind von der BenutzerIn ver nderbar Dadurch k nnen die Pfade und Datei namen der zu generierenden Artefakte einfach spezifiziert werden Module Ein Modul ist eine kompakte Einheit von beliebig vielen Profiles und Commands Module werden m Objecteering UML Profile Builder er stellt und n prof Dateien gepackt Die gepackten Module werden mit Hilfe des mitgelieferten Administrationstools in Modelldatenbanken importiert N here Informationen zu der Administration von Modulen siehe Soft04g Die in den Modelldatenbanken gelagerten Module k nnen im Objectee ring UML Modeler genutzt werden Ein Modul darf durch beliebig viele an dere Module spezialisiert werden Einzige Ausnahme ist das Verbot von Ver erbungskreisen d h ein Profil darf nicht von sich selbst erben Von einem Elternmodul werden alle Modulparameter und alle enthaltenen Profiles ge erbt Commands Um den BenutzerInnen des Objecteering UML Modeler den Zugriff auf J Methoden zu erm glichen werden zu Modulen Commands an gegeben Bei Commands handelt es sich um Befehle die ber Kontextmen s von bestimmten Modellelementen aufgerufen werden Wird ein Befehl akt viert folgt daraus die Ausf hrung der zugeteilten J Methode Da eine J Methode direkt mit einer Metaklasse verbunden ist steht em Command auch mit einer Metaklasse in Beziehung Eine ber einen Command ausf hrbare J Methode darf keine Parameter besitzen und muss zus tzlich
123. ich die Systeme besser zu verstehen zu entwickeln zu warten und zu erweitern e Leistungsfahige Compiler erzeugen Assemblercode aus Hochsprachen der mindestens aquivalente doch meistens sogar bessere Performance erzielt als von Hand geschriebener Assemblercode Heutzutage werden in der Softwareentwicklung objektorientierte Sprachen wie Java C oder Smalltalk eingesetzt um die Datenstruktur und das Verhalten von Objek ten in Klassen zu kapseln Der nachste Abstraktionsschritt in Richtung Softwa replattformunabhangigkeit soll durch graphische Modellierungssprachen wie z B Unified Modeling Language UML bzw textbasierte Sprachen fur die plattformu nabhangige Spezifikation der Semantik von Aktionen wie z B Action Semantic Languages erreicht werden Dieser Abstraktionsschritt erm glicht die Erstellung von plattformunabhangigen Modellen welche von der MDA gefordert wird Zu sammenfassend zeigt Abbildung 1 2 die geschichtliche Entwicklung der Abstrakti onsebenen von Programmiersprachen Kapitel 1 Einleitung Seite 5 Assembler Hochsprachen Code Code Modell PSM Modell Compiler ei Maschinen Code Hochsprachen Code Assembler Code ab 1960 ab 1980 ab 2001 Abbildung 1 2 Programmiersprachen Abstraktionsschritte basierend auf Mell04 Jeder Generationswechsel bringt mehrere Verbesserungen im Bereich Anforderun gen an Programmiersprachen mit sich Durch Abstraktion werden Lesbark
124. ichtslos O5 Supportmoglichkeit Findet man keine Hilfestellung f r ein konkretes Problem m Benutzerhandbuch oder weist das Tool interne Fehler auf sollte Hilfe ber eine Supportm glichkeit verf g bar sein Bei kommerziellen Tools k nnte eine Supportm glichkeit uber einen Help desk ablaufen oder ber pers nliche Betreuer vor Ort Bei Open Source Produkten werden sich die Supportm glichkeiten auf Mailinglisten und Benutzerforen be schr nken O6 Benutzerfreundlichkeit Nat rlich tr gt die Benutzerfreundlichkeit eines Tools sehr zu seiner Akzeptanz be den AnwenderlInnen und seiner Produktivit t bei Die Anforderung Benutzerfreund lichkeit ist im Vergleich zu den bisherigen am schwierigsten objektiv zu bewerten Um einer Scheinobjektivit t entgegen zu wirken wird eine subjektive Bewertung durchgef hrt die sich gro teils auf folgende Kriterien st tzt o Die Steuerung der MDA Aktivit ten ber eine grafische Benutzeroberfl che wird h her bewertet als eine Steuerung ber die Kommandozeile o Falls ein Tool MDA Aktivit ten gesammelt in einer integrierten Umgebung be werkstelligt wird es h her bewertet als ein Tool das diese Aktivit ten nur durch das Hin und Herwechseln zwischen verschiedenen Tools realisiert Kapitel 3 MDA Werkzeuge Seite 55 3 3 Kategorisierung von MDA Werkzeuge Dieses Unterkapitel soll dem Leser eine Orientierung am MDA Werkzeugmarkt geben Zur Zeit wird eine Vielzahl an verschiedenst
125. ie nderungen von Objekt zust nden d e aufgrund von Ereignissen geschehen definiert Jedes Zu standsdiagramm verf gt ber eine Menge von Prozeduren wobei genau eine bei einem Zustands bergang ausgef hrt wird Jede Prozedur besteht wieder aus einer Menge von Aktionen Eine Aktion wird als eine atomare Berech nung wie eine Datenabfrage oder die Erzeugung eines Objektes definiert und wird durch eine Action Semantic Language spezifiziert Aktionen sind hnlich zu Anweisungen auf Codeebene aber mit dem Unterschied dass sie sich auf einer h heren Abstraktionsstufe befinden und keine Annahmen ber die Implementierung treffen Kapitel 3 MDA Werkzeuge Seite 58 Notationsart Notationselemente Entit ten Klassendiagramm Klassen Attribute Einschrankungen Lebenszyklen der Zustandsdiagramm Zustande Entitaten Ereignisse Transitionen Prozeduren Aktionsspezifika Action Semantic Language Aktionen tionen Tabelle 3 1 Executable UML Konzepte nach Mell02 Ein Executable UML Modell enth lt alle notwendigen Details um die Ausf hrung Verifikation und Validierung unabh ngig von der Implementierung zu unterst tzen Es werden aber keine Entwurfs oder Codedetails 1m Modell angegeben um das Modell auszuf hren Daher k nnen auch Testf lle anhand des Modells ausgef hrt werden um Anforderungen des Systems relativ fr h 1m Entwicklungsprozess zu berpr fen Executable UML Tools brauchen besondere Funktionen um
126. ie von Compuware bereitgestellten Transformation Patterns modifiziert werden Im Folgenden wird die Erstellung von Implementation Patterns genauer besprochen Der erste Schritt f r die Entwicklung eines Implementation Patterns stellt die Aus wahl des in Code zu transformierenden Metamodells d h Quellmetamodell dar Sobald die ArchitektIn das relevante Metamodell ausw hlt kann mit der eigentli chen Erstellung der Transformationsspezifikation begonnen werden Optimal bietet f r den Entwurf von Implementation Patterns eine propriet re Sprache genannt Template Pattern Language TPL Die Sprache TPL TPL ist f r die Erstellung von Code Patterns und Transformationen von MOF basierten Modellen z B Datenbank oder Pr sentations Modell zu Syntax basierten Sprachen z B Java oder XML konzipiert In Optimal wird ausschlie lich die Sprache TPL f r die bereitgestellten Transformationen von dem Applikati ons Modell zu Java XML und SQL Artefakten genutzt TPL Skripte werden in Java Klassen kompiliert die in OptimalJ als Implementation Pattern Module impor tiert werden Diese Module haben Zugriff auf die Repository API um die fur den Generierungsprozess notwendigen Modellinformationen abzufragen Die Java Klassen nehmen auf MOF basierende Modelle als Eingabe und erzeugen Artefakte wie z B XML oder SQL Dokumente als Ausgabe Ein TPL Skript gliedert sich in einen Deklarationsteil und einen Skriptkorper Der Deklarationsteil s
127. in Programmierkonzepten und Programmiersprachen basieren Code besitzt eine zu niedrige Abstraktionsebene Wiederverwendung basiert auf einer zu feinen Form Programmspezifikationen s nd stark mit hrer Infrastruktur verflochten u Ee E Business to Software Mappings werden nicht archiviert Diese vier Hauptprobleme der Softwareentwicklung werden in den nachsten Ab schnitten genauer erl utert Dabei werden potentielle L sungsm glichkeiten durch den Einsatz der modellgetriebenen Softwareentwicklung angef hrt und ausf hrlich beschrieben Code besitzt eine zu niedrige Abstraktionsebene In Programmcode wie z B Java oder C werden viele plattformspezifische Details und Angaben ber Datenstrukturen w e z B Hashtables oder Arrays oder Algo rithmen wie z B Such oder Sortieralgorithmen implementiert Die eigentliche Problemstellung Dom nenwissen ist nicht unmittelbar erkennbar da sie ber viele Textdateien fragmentiert vorliegt und mit technologischen Details vermischt ist Dieses Problem ruft nach einer neuen h heren Abstraktionsebene f r Softwarespezi fikationen um mit immer komplexer werdenden und einer stark wachsenden Anzahl von verschiedenartigen Softwaresystemen wie z B mobile Ger te Embedded Sys tems fertig zu werden Die Antwort welche von der Object Management Group OMG propagiert wird hei t Model Driven Architecture MDA Dieser Softwareentwicklungsansatz ist ein weiterer evolution rer S
128. in UML Klassendiagramm oder ein ER Diagramm ein Softwaremodell Nat rlich stellt ein Quelltext ein u erst platt formspezifisches Modell dar Wie nun wohldefinierte Modelle spezifiziert werden zeigt der nachste Abschnitt uber Metamodelle Metamodelle Im Abschnitt Modelle wurde ein Modell als Beschreibung eines Systems in einer wohldefinierten Sprache die vom Computer exakt verarbeitet werden kann defi niert Dabei wurde die wohldefinierte Sprache als gegeben angenommen In diesem Abschnitt ist die Beschreibung einer solchen wohldefinierten Sprache von Interesse um die weiteren Zusammenh nge des MDA Ansatzes verstehen zu k nnen Programmiersprachen werden im Allgemeinen durch Grammatiken definiert welche m gliche Varianten von Zeichenfolgen mittels Token bestimmen Durch einen Par ser wird berpr ft ob die Syntax der Anweisungen g ltig ist Als Definition von Sprachen sind Grammatiken nur fur textbasierte Sprachen relevant Da Modellie rungssprachen im Allgemeinen nicht auf Text basieren sondern uber grafische Ele mente der Systembeschreibung verf gen wird ein eigener Mechanismus ben tigt um Modellierungssprachen im MDA Bereich zu definieren Da UML die Hauptmo Kapitel 2 Model Driven Architecture Seite 23 dellierungssprache der modellgetriebenen Softwareentwicklung darstellt wird im Folgenden der Metamodellierungsansatz der OMG vorgestellt Ein Modell definiert welche Elemente in einem System existieren d
129. ingesetzt um die mit dem 1UML Modeler erstellten Modelle auszuf hren Daf r werden die Modelle durch das Werkzeug in C Code transformiert und sind somit im 1UML Modeler aus f hrbar und testbar Der f r den Einsatz von 1UML vorgeschlagene Entwicklungs prozess ist aquivalent zu dem von Nucleus BridgePoint definierten Entwicklungs prozess Der einzige Unterschied besteht darin dass IUML keinen Model Debugger anbietet und somit die letzte Phase des Entwicklungsprozesses wegf llt IUML und ICCG basieren auf der Action Specific Language ASL ASL ist eine implementie rungsunabhangige Sprache fur die Spezifikation von Aktionen in Executable UML Modellen Weiters ist ASL kompatibel zu Action Semantics fur UML ASL wird in 1UML nicht nur fur die Spezifikation von Aktionen eingesetzt sondern auch fur die Definition von Einschr nkungen In 1CCG wird ASL f r die Definition von Trans formationsspezifikationen eingesetzt Fur nahere Informationen zu ASL wird auf IKCO1 verwiesen UML bietet umfangreiche Testm glichkeiten von Systemen auf Modellebene Um ein auf Executable UML basierendes Modell testen zu k nnen m ssen vorher die Anfangsbedingungen des Modells w e Objekte Objektzust nde und Signale be stimmt werden Zus tzlich m ssen Testmethoden vorhanden sein die beschreiben wie ein Modell simuliert werden soll wie z B durch die Angabe der Sendesequenz von Signalen Im 1UML Modeler werden die Anfangsbedingungen und die Testme thoden
130. ise Java Beans dienen Schl sselwort Wert Paare Die Semantik von Modellelementen kann durch die Angabe von Schl sselwort Wert Paaren noch genauer spezifiziert wer den Dabe wird ber cksichtigt welche Schl sselwort Wert Paare f r welche Stereotype oder Metaklassen angegeben werden d rfen Objecteering UML verwendet Schl sselwort Wert Paare um das Konzept von Markierungen zu realisieren Beispielsweise k nnte f r eine Klasse welche mit dem Stereotyp Entity Bean versehen ist ein Schl sselwort Wert Paar f r das Management der Persistenz angegeben werden wie persistenz cmp fur Container verwaltete Persistenz oder persistenz bmp f r Bean verwaltete Persistenz Einschr nkungen Eine Einschr nkung kann Restriktionen und Beziehungen ausdr cken die mittels UML Notation nicht definierbar sind Die Einschran kung ist n nat rlicher Sprache zu formulieren da keine semantische Auswer tung der Einschr nkungen m Tool vorgesehen ist Allgemein ist die Defini tion von Einschr nkungen f r jede Instanz des Typs ModelElement oder da von spezialisierten Typs m glich Mittels Profiles k nnen aber auch eigene Einschr nkungen f r Metaklassen und Stereotype spezifiziert werden Notes In Profiles k nnen zu Metaklassen oder Stereotype sogenannte Notes zugeordnet sein Dadurch ist es im Objecteering UML Modeler m glich No tes zu den Instanzen der entsprechenden Metaklassen oder zu Instanzen von der Metaklasse spezialisi
131. ition von Modelltransformationen Mittels Transformationen sollen neue Informationen in das Modell aufgenommen werden wobei die eigentliche Semantik nicht verloren gehen darf Weiters m ssen auch Designentscheidungen bei Modelltransformationen ber cksichtigt werden Da man in MDA von einem sehr abstrakten und wenig detaillierten Modell PIM aus geht und dieses in ein konkretes und detaillierteres Modell PSM transformiert ist es mitunter sinnvoll mehrere Transformationsschritte und temporare Zwischenmo delle einzuf hren Somit k nnen die Aufgabenbereiche der Transformationen besser getrennt und die Komplexitat der einzelnen Transformationen verringert werden Abbildung 2 8 beschreibt einen mehrstufigen Transformationsprozess ns abstrakt konkret wenig Details viele Details Abbildung 2 8 mehrstufiger Transformationsprozess Der Hauptanwendungsfall von Transformationen innerhalb der MDA stellt vermut lich die Transformation eines PIMs in ein PSM dar Fur diesen Anwendungsfall wer den Modelltransformationsregeln auf das PIM angewandt um ein gewunschtes PSM zu bekommen Um ein fertiges Softwaresystem zu erhalten wird aber eine zweite Transformation notwendig namlich die Transformation des PSMs zu Softwarearte Kapitel 2 Model Driven Architecture Seite 31 fakten Generell k nnen zwei Transformationsarten unterscheiden werden n mlich Modell zu Modell Transformationen und Modell zu Code Transformationen Die Spezifik
132. kannt ist unterst tzen Somit k nnen beispielsweise Funktionalit ten f r Java Transformationen auch f r EJB Transformationen wiederverwendet werden Durch die Modellierung von Transformationen sind d e technischen Architekturen von Kapitel 3 MDA Werkzeuge Seite 49 Plattformen verglichen mit textuellen Transformationsspezifikationen einfacher zu verstehen 3 2 3 Artefaktgenerierungskriterien Um aus konkreten und detaillierten Modellen lauff hige Softwaresysteme zu gene rieren wird eine letzte Transformation notwendig n mlich eine Modell zu Code Transformat on Theoretisch kann Code auch als Modell betrachtet werden und da her eine Modell zu Code Transformation als gew hnliche Modelltransformation gesehen werden Doch in der Praxis zeigen sich spezielle Anforderungen an die Ar tefaktgenerierung wie beispielsweise die Ber cksichtigung von manuellen nde rungen n textbas erten Artefakten Im Folgenden werden die Anforderungen der Kategorie Artefaktgenerierung aufgelistet und beschrieben Al Gesch tzte Bereiche Da heutzutage eine 100 1ge Codegenerierung meist nicht erreicht wird muss ein Gro teil der Gesch ftslogik manuell hinzugef gt werden Um manuelle nderungen im generierten Code nicht beim n chsten Generierungszyklus zu verlieren sollten MDA Tools Schutzmechanismen f r manuell erstellte Codefragmente anbieten Je ausgereifter dieser Schutzmechanismus implementiert ist desto weniger manuelle Nachar
133. lates gesteuert die die daf r notwen digen Informationen aus den XDoclet Tags und aus dem Quelltext der Dateien be ziehen Ein Grund f r die Entstehung des XDoclet Projektes war die m hsame Ent wicklung von EJB Komponenten Da eine Entity Bean bis zu sieben Dateien ben tigt und sich eine nderung in einer Datei auf mehrere Dateien auswirkt wurde die Forderung nach automatisierter Erstellung und einfacherer Handhabung st rker XDoclet l st dieses Problem indem nur mehr eine Datei die alle relevanten Infor mationen als Metadaten enthalt erstellt wird und die restlichen Dateien werden dar aus automatisch erzeugt AndroMDA nutzt XDoclet als zweiten Codegenerator um die Transformationen fur Velocity zu vereinfachen Die erzeugten Dateien des ersten Generators Velocity durfen XDoclet Tags enthalten Aus diesen Metadaten erzeugt XDoclet die restli chen Artefakte die fur eine lauffahige Anwendung ben tigt werden Kapitel 4 Evaluierung Seite 85 4 4 4 MDA Cartridges MDA Cartridges definieren die Transformationen von Modellelementen die durch Stereotype und Schlusselwort Wert Paare gekennzeichnet wurden in beliebige Text dateien meistens Quelltext oder Verteilungsinformationen Mit der Standardinstal lation werden Cartridges fur folgende Plattformen bereitgestellt Bezeichnung Beschreibung BPM4Struts erm glicht die Gesch ftsprozessmodellierung f r Jakarta Struts woraus Webseiten Form und Aktionsklassen gen
134. le helfen die Struktur und das Verhalten eines Systems zu spezifizieren und zu kom munizieren Existiert bereits ein Softwaresystem und gilt es dieses zu erweitern so tr gt eine Dokumentation in Form von Modellen zum besseren Verst ndnis des Sys tems und zur rascheren Erweiterung bei In jedem Softwareentwicklungsprozess wird versucht Fehler fr hzeitig zu entdecken Bei dem Einsatz von Modellen ist eine fr he Simulation von Prototypen m gl ch Fehler k nnen auf einer abstrakteren Ebene schneller und g nstiger ausgemerzt werden als auf Quelltextebene Au erdem helfen Modelle bei der Implementierung des Systems durch die automatische Gene rierung von Skeleton Code und Templates Dieser Ansatz der Entwicklung von Softwaresystemen wird durch die MDA fortgesetzt um die automatische Erstellung von lauffahigen Applikationen aus Modellen zu erm glichen Sprache UML Java geschrieben in beschreibt Abbildung 2 2 Definition und Aufgabe von Modellen Doch heutzutage bestehen noch einige Limitationen bei dem Einsatz von Modellen in der Softwareentwicklung und somit steht die Softwareentwicklung noch weit hin ter reiferen Industrien wie der Automobilindustrie oder der Elektrotechnik Sogar im Kapitel 2 Model Driven Architecture Seite 21 Hardwaredesign werden Modelle bei weitem effizienter eingesetzt als 1m Software design Folgende Probleme behindern einen effizienteren Einsatz von Modellen n der Softwareentwi
135. lement der Menge durchgef hrt ModelElement OwnedElement Owner Part Ronis A 0 1 Visibil GeneralClass Name String Abbildung 4 17 Auszug aus dem Objecteering UML Metamodell Das folgende J Programm ist ein Beispiel f r den Einsatz des Diffusionsmechansi mus Die Aufgabe dieses Programms ist die Ausgabe aller ffentlichen Attribute der Klassen eines Packages Der Zusammenhang zwischen Packages Klassen und Attri buten auf Metamodellebene wird n Abbildung 4 17 gezeigt F r d e Erstellung des Programms ist die Kenntnis des Metamodells von gro er Bedeutung da die Meta modellelemente 1m Programmcode korrekt angesprochen werden mussen Die Me thode listAttributes wird zur Metaklasse Package hinzugefugt Auf Metamodell ebene besitzt ein Package Elemente vom Typ NameSpace siehe in Abbildung 4 17 die Rolle OwnedElement da die Klasse Package von der Klasse NameSpace abge leitet wird Mit OwnedElementClass k nnen nun alle Klassen aus allen Elementen eines Packages herausgefiltertt werden Die vordefinierte Hilfsmethode StdOut write String s gibt den bergebenen String ber die Konsole aus Da nach wird eine Diffusion f r alle Attribute einer Klasse mit Hilfe einer anonymen Methode angewendet wobei noch zus tzlich ein select Operator angegeben wird um nur ffentliche Attr bute zu ber cksichtigen In dem darunter liegenden Pro Kapitel 4 Evaluierung Seite 103 grammblock werden die Namen
136. lichen Arten der Model le des MDA Paradigmas zu erl utern muss zuvor gekl rt werden was eigentlich der Begriff Modell m der Informatik bedeutet Au erdem muss festgelegt werden wie ein Modell durch ein Metamodell beschrieben und was unter dem Begriff Metamo dell verstanden wird Modelle Ein Modell ist eine Abstraktion von einer in der Realit t existierenden Entit t Mo delle werden verwendet um uninteressante Details zu verschweigen und wichtige Aspekte ins Rampenlicht zu r cken Folgende Eigenschaften basierend auf Seli03 charakterisieren Modelle nicht nur im Softwarebereich e abstrakt Modelle abstrahieren von irrelevanten Details und stellen relevante Aspekte n den Mittelpunkt l http www omg org technology documents formal corbaservices htm Stand 14 2 2005 Kapitel 2 Model Driven Architecture Seite 20 e einfach Modelle besitzen durch grafische Notationselemente eine menschen freundliche Repr sentationsform e pr zise Durch formale Modellierungssprachen k nnen pr zise und bere chenbare Modelle erstellt werden e voraussagend Durch Modelle k nnen Probleme schon im Vorfeld erkannt werden wodurch auf diese besser reagiert werden kann e g nstig Modelle sind um einiges kosteng nstiger in der Erstellung als die konkrete Realisierung Aus den aufgelisteten Eigenschaften ergeben s ch mehrere Vorteile d e f r einen Einsatz von Modellen be der Erstellung von Softwaresystemen sprechen Model
137. ll annotiert werden Jedes Com ponentSegment verf gt ber ein MDA Markierungsfenster Uber dieses Fenster ist die Karteikarte EJB 1 2 2 0 Abbildung 5 6 verf gbar n der die Realisierungsm g lichkeiten der Bean ausgewahlt werden konnen Class Specification General Attributes Operations Template Parameters Inner Elements Relatiar s Stereotypes Tagged Values Constraints MDA Marks ArcStyler Java WehSenice EJB 1 7 2 0 WLS 6 5 CMP WLS 68 Core Profile JNO Name Local JNDI Name BeanType Senkemotelnterfaces SenlLocallnterfaces FeatureDftiInterface PersistenceManagement Cartridge Defaut isReentrant False stateManagement Transaction ype Container Containerlransaction Required Ssessionsynchronization False CommitOptian Cartridge Defaut Timeout enn entries ChIP ersion AbstractSchemahlame SenDftF actories EmptyParameterList la ann leid Jemen a a 2 a a Ia allal alalla d an 2 a CD ANER ba E d r Abbildung 5 6 Markierungsfenster eines ComponentSegments Erstellung des logischen Web Subsystemmodells Die WebAccessors Cartridge fokussiert auf die View und Controllerschicht des MVC Musters und wird verwendet um die Interaktion der Prasentationsschicht mit der darunterliegenden Geschaftslogikschicht zu modellieren Die WebAccessors Cartridge stellt zwei Hauptkonzepte zur Verf gung n mlich Representer Klassen fur die Erstellung der Viewschicht und Accessor Klassen
138. lle oder sogar voll st ndige Testsuiten spezifiziert werden und aus diesen kann der ben tigte Code f r die Durchf hrung der Tests abgeleitet werden Um die Verteilung der Komponenten zu beschleunigen bzw zu automatisieren k nnen Skripte die die Verteilung der Komponenten bzw Initialisierung der Testdaten vornehmen aus den Modellen ab geleitet werden 3 2 Kriterienkatalog f r MDA Werkzeuge Eines der Hauptforschungsziele dieser Diplomarbeit ist die Erstellung eines Krite rienkataloges fur die Evaluierung von MDA Tools Anhand des Kriterienkataloges soll der Erfullungsgrad der MDA Unterst tzung eines Tools welches von sich be hauptet das MDA Paradigma umzusetzen bestimmbar sein Um einen strukturierten berblick ber die Anforderungen zu erm glichen werden diese in Kategorien eingeteilt Im Folgenden werden die Kategorien identifiziert und danach hre Anforderungen besprochen Kapitel 3 MDA Werkzeuge Seite 40 Im ersten Teil dieses Abschnitts wurden m gliche Aktivit ten eines Entwicklungs prozesses mit MDA Ansatz beschrieben Betrachtet man den vorgeschlagenen Ent wicklungsprozess so sind daraus drei Kategorien welche besonders von der Auto matisierung durch Tooleinsatz profitieren ableitbar o Modellerstellung Dieser Bereich besch ftigt sich mit Anforderungen an die gra fische Modellierung der Softwaresysteme aber auch nichtgrafische Elemente wie Einschr nkungen oder plattformspezifische Markierungen
139. llten zumindest f r die Entwicklung von Softwaresystemen und f r die Erstellung von Metamodellen und Transformationen zwe verschiedene Editionen angeboten werden E n Tool das alle Rollen eines Softwareentwicklungsprozesses unterst tzt wirkt schnell berladen und besitzt dadurch unzureichende Benutzerfreundlichkeit O3 Angebotene Schulungen Wie bei der Einleitung dieser Kategorie erw hnt m ssen die BenutzerInnen lernen mit dem Tool umzugehen Dies kann durch angebotene Schulungen entweder direkt beim Toolhersteller oder bei speziellen Beratungsunternehmen erleichtert werden Auch f r die Akzeptanz des Tools bei den neuen BenutzerInnen ist eine gute Ein schulung forderlich O4 Werkzeugdokumentationen Kapitel 3 MDA Werkzeuge Seite 54 Wohl eine der wichtigsten Anforderungen stellt die Forderung an guter und ausrei chender Dokumentation des Werkzeuges dar Dabe soll die interne Struktur des Tools gut beschrieben sein und zus tzlich sollten Tutorials f r die wichtigsten Pro jekte verf gbar sein Weiters sollten Beispielanwendungen mit der Distribution mit geliefert werden um den EntwicklerInnen eine erste Orientierungshilfe bei der Er stellung eigener Anwendungen zu geben Speziell fur die Erstellung bzw Modifikation von Metamodellen und Transformati onen sind Dokumentationen und ausf hrliche Referenzbeispiele unbedingt notwen dig Denn ohne diese Hilfen scheint eine erfolgreiche Erweiterung des Tools aus s
140. ls Container f r Tools gesehen werden der Services fur folgende Aufgaben definiert e Interaktionen mit anderen Werkzeugen die mittels TAS im ArcStyler einge bunden sind GUI Integration Men s Toolbars Panels Selektionsmanagement von Modellelementen MDA Cartridge Management Verbindung zwischen verschiedenen Repository Schnittstellen und Profiles Management von Profiles und Markierungen TAS bietet Erweiterungspunkte um selbstentwickelte oder von Drittanbietern er stellte Werkzeuge im ArcStyler zu integrieren Diese integrieten Werkzeuge k nnen die vorher definierten Services ber Schnittstellen benutzen Weitere Informationen ber die TAS API und Anleitungen ber die Entwicklung eigener Plugins findet man in IO 03b 4 6 Objecteering UML Hersteller SOFTEAM Webseite http www softeam com Testversion Objecteering UML Enterprise Edition Version 5 3 0 f r Windows Kapitel 4 Evaluierung Seite 93 4 6 1 Einf hrung Das franz sische Unternehmen SOFTEAM betreibt bereits seit dem Jahr 1991 lange bevor der Begriff MDA definiert wurde intensive Forschung und Entwicklung m Bereich der modellgetriebenen Softwareentwicklung Im Jahr 1994 begann SOFTEAM in ihrem UML CASE Tool Objecteering UML unter dem Begriff Ay pergenercity Soft01 mit der Integration von Features fur modellgetriebene Soft wareentwicklung Das Konzept hinter dem Begriff Hypergenercity hatte bereits viele Gemeinsamkeiten zu dem was heutzutage un
141. lstudie Seite 135 Durch die Generierung des Infrastrukturcodes wird ein fester Coderahmen f r alle Dateien vorgegeben Dadurch kann die Codequalitat gesteigert und die Wartung verbessert werden Durch den Einsatz des MDA Paradigmas verf gt man durch das PIM ber eine gute Dokumentation die n cht vom Code abweicht da deser vom Mo dell abgeleitet wurde Negative Aspekte Es werden keine Aktivitats oder Zustandsdiagramme f r Gesch ftslogikme thoden geboten Somit m ssen Geschaftslogikmethoden bis auf die Metho densignatur manuell erstellt werden Einige Methoden in den Controllerklassen m ssen mit manuell erstelltem Code erg nzt werden Da die handische Programmierung nicht g nzlich erspart bleibt werden tief gehende Kenntnisse uber den generierten Code ben tigt um die aus dem Modell n cht generierbare Funktionalit t zu implementieren Bei der Verschiebung oder Umbenennung von Paketen oder Klassen in der Elementhierarchie werden be der n chsten Transformation neue Quelltext dateien generiert Sind in den alten Quelltextdateien manuelle nderungen vorgenommen worden werden diese in die neuen Dateien nicht automatisch bernommen Die EntwicklerIn muss die manuellen Erg nzungen von den alten in die neuen Dateien h ndisch bertragen ber verf gbare Methoden der Benutzeroberfl chenelemente der WebAc cessors Cartridge werden keine Dokumentationen angeboten Wird zum Bei spiel ein Textfeld als Pass
142. lt sondern s nd global von jeder Funktion erreich bar Da nun mehrere Funktionen unkontrollierten Zugriff auf globale Datenstruktu ren haben k nnen m ssen bei einer nderung in der globalen Datenstruktur mehrere Funktionen modifiziert werden auch wenn diese nderung nur wegen einer einzigen Funktion notwendig ist Die Antwort auf letztgenanntes Problem waren Objekte Diese erm glichten die Kapselung von Daten und hren zugeh rigen Funktionen Somit stieg auch das Wie derverwendungspotential stark an Doch schon bald erkannte man dass auch Objek te nicht die F higkeit besa en die erh hte Komplexit t von verteilten Anwendungen zu kompensieren Gerade m Bereich Gesch ftsapplikationen der einen Gro teil von Softwareapplikationen repr sentiert wurde das Bed rfnis nach kosteng nstigerer und effizienterer Programmierung k rzere Time to Market sichtbar Diese Er kenntnis war die Geburtsstunde der Komponenten Eine Komponente ist eine Menge von eng zusammenarbeitenden Objekten die mit einer Menge von wohldefinierten Schnittstellen zur Au enwelt gekoppelt wird Mit dem Einzug von Komponenten wurden Enterprise Java Beans EJBs SUNO3b u erst erfolgreich und mit ihnen wurden Applikationsserver popular Um die Funk tionsweise von Komponenten und Applikationsserver wie z B Jboss BEA WebLo gic zu verdeutlichen soll folgendes Beispiel dienen Jeder CD Player liest und spielt CDs da ein einheitlicher CD Standard
143. lusselwort Wert Paaren fur Stereotype oder Referenzen auf Metaklassen zu modellieren Die optionale Angabe von Pa rametern Standardwert ist NULL fur Schlusselwort Wert Paare ist erlaubt Werden keine Parameter definiert so sind Schl sselwort Wert Paare nur f r die Markierung einer erfullten Eigenschaft z B persistent eines Elementes einsetzbar Die Parameter sind aber nicht typisierbar denn bis auf den Stan dardwert NULL werden Parameter generell als Strings verarbeitet In Objec teering UML wird das von OMG02a geforderte Markierungskonzept um die fur die Transformationen notwendigen Entscheidungsalternativen zu bestimmen durch die Definitionsm glichkeit von Schl sselwort Wert Paartypen umgesetzt Einschr nkungen Einschr nkungen werden zu Referenzen auf Metaklassen oder zu Stereotypen angef gt Eine Einschr nkung ist durch ihren Namen 1 dentifizierbar und beinhaltet einen beliebigen Text der die Einschr nkung spezifiziert Leider wird weder OCL noch eine andere Einschrankungsspra che von Objecteering UML unterst tzt Dadurch werden Einschr nkungen semantisch nicht ausgewertet und k nnen f r Transformationen nur be schr nkt gen tzt werden Kapitel 4 Evaluierung Seite 105 Propriet re Konzepte Notes Um bestimmten Typen von Modellelementen zus tzliche Textfrag mente f r Kommentare oder Codeteile zuweisen zu k nnen ist es m glich neue Typen von Notes anzugeben Typen von Notes werden entweder zu Re
144. m L schen der Tabellen DROP TABLE Eintrag DROP TABLE Benutzer Transformation des Web Subsystems Bevor die Transformation des Web Subsystems zu Code begonnen werden kann muss wie bei der Transformation des EJB Subsystems der Codegenerator konfigu nert werden F r die WebAccessors Cartridge reicht die Konfiguration der Ausga bepfade f r die zu generierenden Artefakte und die Konfiguration des Tomcat Web servers Um die Modelle auf Konsistenz zu pr fen ist die WebAccessors Cartridge ebenso wie die WLS Cartridge mit einer Verify Funktion ausgestattet Diese M g lichkeit sollte vor jeder Modelltransformation genutzt werden um keine fehlerhaften Kapitel 5 Fallstudie Seite 126 Modelle zu transformieren Mittels der Funktion Generate wird die Transformation des Web Subsystemmodells gestartet Eine Accessor Klasse wird in eine Java Klasse mit dem Namen der Accessor Klasse transformiert Das zur Accessor Klasse gehorende Aktivitatsdiagramm wird als inne re Klasse mit dem Namen vertex top implementiert Die innere Klasse vertex top beinhaltet f r jeden Zustand oder Aktivit t des Aktivitatsdiagrammes eine innere Klasse mit dem Namen vertex x wobei x f r den Namen des jeweiligen Zustandes oder der jeweiligen Aktivit t steht Das folgende Codefragment zeigt einen kleinen Auszug der generierten Date An meldeAccessor Jeder Zustand wird als innere Klasse der inneren Klasse vertex top implementiert Die inneren Klassen erben abh
145. marktet Diese Entwicklung birgt aber auch eine potentielle Gefahr fur die MDA Durch unausgereifte oder neu vermarktete Produkte die den Anspr chen der Pro grammierInnen oder ProjektleiterInnen nicht gerecht werden kann die MDA Entwicklung leicht zum Stocken gebracht oder vollst ndig gestoppt werden Deshalb wird in diesem Kapitel der MDA Werkzeugsektor eingehend besprochen um eine Vorstellung von gut realisierten Werkzeugen zu geben Das Unterkapitel 3 1 besch ftigt sich mit einem m glichen Entwicklungsprozess f r den Einsatz des MDA Paradigmas Im Abschnitt 3 2 werden die Anforderungen an MDA Werkzeuge im Laufe eines Entwicklungsprozesses n einem Kriterienkatalog gesammelt Danach wird im Unterkapitel 3 3 eine m gliche Kategorisierung von MDA Tools diskutiert Weiters wird ein grober berblick ber die am Markt ange botenen Produkte gegeben um eme erste Entscheidungsgrundlage zu bieten ob ein Tool f r ein konkretes Projekt sinnvoll einzusetzen ist Kapitel 3 MDA Werkzeuge 3 1 MDA Entwicklungsprozess Seite 37 Um die Anforderungen an MDA Werkzeuge zu definieren m ssen wir uns zuerst die Aktivit ten eines Softwareentwicklungsprozesses mit MDA Ansatz ansehen Anhand der Aktivit ten wird ersichtlich welche T tigkeiten in einem MDA Projekt auftauchen und entscheidbar welche T tigkeiten durch Werkzeugeinsatz automati siert werden k nnen Im Folgenden wird eine m gliche Variante eines MDA Entwicklungspr
146. mente k nnen n verschiedenen Bereichen ge funden werden Haupts chlich werden Stereotype und Schl sselwort Wert Paare als Markierungen f r Modellelemente eingesetzt In der Praxis wird eine Kombination aus typbasierten und instanzbasierten Abbil dungen fur den erfolgreichen Einsatz von Transformationen erwartet Eine typbasier te Abbildung bildet einen Typ des Quellmodells in einem Typ oder in mehrere Ty pen des Zielmodells ab Ist nun keine Moglichkeit fur das Anbringen von Markie rungen vorgesehen werden nur Informationen der Metamodelle des Quell und Zielmodells fur die Generierung des Zielmodells verwendet Doch oft bedarf es an Markierungen im Quellmodell damit das Zielmodell die geforderten funktionalen und nicht funktionalen Eigenschaften erfullt die aber aus dem Quellmodell nicht direkt abgeleitet werden k nnen Viele der heute erh ltlichen MDA Kapitel 2 Model Driven Architecture Seite 34 Entwicklungswerkzeuge setzen eine Kombination aus typbasierten und instanzba sierten Abbildungen ein siehe ArcStyler Objecteering UML Optimal in Kapitel 5 Diese Werkzeuge ziehen f r Typbasierte Abbildungen Stereotypen und UML Metaklassen und f r Instanzbas erte Abbildungen Schl sselwort Wert Paare heran Musterbasierte Abbildungen F r fters vorkommende Anordnungen von Modellelementen 1m Quellmodell wel che auf bestimmte Anordnungen von Modellelementen m Zielmodell abgebildet werden k nnen sogenannte musterbasie
147. mework basierend auf KC04 4 3 OptimalJ Hersteller Compuware Corporation Webseite http www compuware com Testversion OptimalJ 3 1 Professional Edition Windows Version 4 3 1 Einfuhrung OptimalJ ist eine Enterprise Application Entwicklungsumgebung in der einsatzfahi ge J2EE Applikationen direkt aus UML Modellen erzeugt werden MDA Konzepte werden mit ausgereiften Patterns CCO4a f r die Erstellung und Transformation von Kapitel 4 Evaluierung Seite 71 Modellen kombiniert Vertrieben wird das Tool von der Firma Compuware Corpora tion und befindet sich zurzeit in der Entwicklungsversion 3 1 OptimalJ ist in drei verschiedenen Editionen Architecture Edition Professional Edition und Developer Edition erh ltlich wobei jede Version auf eine bestimmte Rolle der m Software entwicklungsprozess involvierten Mitarbeiter fokussiert Die Developer Edition wird f r EntwicklerInnen angeboten die Arbeiten an J2EE Artefakten vornehmen jedoch ohne auf Modellierungsfeatures zur ckzugreifen Dabei soll die EntwicklerIn nicht mit Infrastrukturcode konfrontiert werden sondern die Geschaftslogik mplementieren und dadurch die Anwendung vervollst ndigen Die Professional Edition erweitert die Developer Edition und ist f r erfahrene Ent wicklerInnen und Software DesignerInnen vorgesehen die die Analyse und das De sign anhand von Modellen durchf hren Die erstellten Modelle werden zuerst in auf J2EE spezialisierte Modelle un
148. mit Legacy Code zu testen Im Model Builder Abbildung 4 2 k nnen Modelle mit Hilfe von Dom nen Paketdiagrammen Klassendiagrammen Zustandsdiagrammen und Aktionsbeschrei bungen erstellt werden Aus diesen prim ren durch die BenutzerIn erstellbaren Dia grammen k nnen weitere Diagrammarten durch das Werkzeug automatisch erstellt werden wie z B Objekt Kollaborationsdiagramme oder Zustands Transitions Tabellen Diese sekund ren Diagrammarten sollen der BenutzerIn einen besseren berblick bieten und verschiedene Sichten auf das modellierte System gew hren Kapitel 4 Evaluierung Seite 66 BrideePoint Model Builder Index Window File Components Configuration Branches Preferences Hein Coman WYorkssace Microwavecven 0 iPr ogan Va WAR 20 7 P N Jk gt TEE Test Subeysiem WAR 20 7 Ststechert Teal Sequences MAI 21 7 derweil Action Auvetting Test Sequence sn Toohing Complete Performing Test Sequence 1 Performing Test Sequence 2 gt Copyrigt te 1992 2005 Project Technolgy Ne end ts licensors All Rights Reserved Abbildung 4 2 Hauptansicht des Model Builder Der Model Builder berpr ft die Modelle auf die korrekte Verwendung der Modell elemente und die Syntax der in Object Action Language OAL AT04b spezifizier ten Aktionsbeschreibungen OAL st eine Sprache welche die Action Semantic f r UML 1 5 umsetzt Zus tzlich zu den Modellierungsaspekten bietet der Model Buil der Funktion
149. mspezifische MDA Werkzeuge nennnnnoesssssseeeeeeeennnsnssssss 60 MDAs WV Erkner 61 mitgelieferte Produkte des AndroMDA Frameworks 83 MDA Cartridges des AndroMDA Frameworks 000eeeeeneneseesessessssss 85 Auszug aus dem Stereotypverzeichnis der EJB Cartridge 85 MDA Cartridges f r ArcStyler ccccccccccccccccccccccccccccccccccccccccccceceeeees 91 mitgelieferte Module von ObiecteermngeUMl cceeseeeeeeeeees 99 Modellierungsanforderungen ccccccccccccscssssssssseesseeeeceeeeeeeeeeeeaaaaas 108 Modelltranstformatonsanforderungen 108 Artefaktgenerierungsanforderungen 0oooooeeeeeneesennsssssssssseerereeeeeo 109 Toolinteroperabilit ts Toolintegrationsanforderungen 109 Tabelle 4 10 konomische Anforderungen 0u00ussssesnnnnnnnnnnnnssnnennennennnn 109 Literaturverzeichnis Andr04 Arlo04 AT04a ATO4b Bare02 Bene04 CC04a CC04b AndroMDA Team Doc for 3 0M3 SNAPSHOT http www andromda org 14 12 04 2004 J Arlow I Neustadt Enterprise Patterns and MDA Building better soft ware with Archetype Patterns and UML Addison Wesley Verlag 2004 Accelerated Technology Nucleus BridgePoint Development Suite Get ting Started Guide mitgeliefert in der Evaluationsversion der Nucleus BridgePointumgebung 6 1 beziehbar unter http www acceleratedtechnology com 12 1 2005 2004
150. n da sich diese durch den Einsatz von MDA Werkzeugen enorme Produktivit tssteigerungen erhoffen Ohne Vorkenntnisse ber MDA ist die Auswahl des einzusetzenden Werkzeuges u erst schwer zu treffen da eine Vielzahl an Werkzeugen angeboten wird und sich diese stark im Funktionsumfang unterschei den Einige Werkzeuge erzeugen einen Gro teil der Applikationen f r eine bestimm te Plattform oder f r einen bestimmten Einsatzbereich doch im Allgemeinen werden nur Codefragmente erstellt die h ndisch ausprogrammiert werden m ssen Durch diese Vielfalt von MDA Werkzeugen besteht d e Gefahr dass unpassende Werkzeu ge f r Projekte eingesetzt werden und dadurch das Risiko f r ein Scheitern des Pro jektes stark ansteigt l http www omg org mda products success htm Stand 1 1 2005 Kapitel 1 Einleitung Seite 12 Um einerseits eine exaktere Vorstellung von dem Begriff MDA zu bekommen und andererseits den aktuellen Stand der Technik zu bestimmen wird eine konkrete Fall studie durchgef hrt n der ein MDA Werkzeug f r die Erstellung einer mehrschich tigen Webapplikation eingesetzt wird Weiters werden durch die Fallstudie Bereiche der Softwareentwicklung aufgezeigt die durch den Einsatz von aktuellen MDA Werkzeugen stark profitieren au erdem wird auch gekl rt welche Bereiche noch Forschungsaktivit ten ben tigen Durch die Kategorisierung von MDA Werkzeugen und durch die n einem Kriterienkatalog gesammelten Anforderungen an MDA
151. n sollten Toolhersteller die Nutzung von MOF zur Erstellung neuer Metamodelle erlauben und weiters auch in ihren Tools unterst tzen Dabei sollte in den Tools ein MOF Modellierungseditor angeboten werden der die korrekte Erstellung eines auf MOF basierenden Metamodells er leichtert Kapitel 3 MDA Werkzeuge Seite 43 Neue Metamodelle erlauben nicht nur die Unterst tzung zuk nftiger und dom nen spezifischer Modellierungstechniken sondern auch die Nutzung von lteren Para digmen M4 Repository f r Meta Modelle Ein Repository Modelldatenbank ist eine m glicherweise verteilte Komponente in der Modelle gespeichert werden und die Zugriff auf diese Modelle mittels wohl definierter Schnittstellen erm glicht Diese Schnittstellen k nnen entweder durch standardisierte oder auch durch proprietare APIs implementiert werden Eine weitere Variante stellen Abfragesprachen dar die Modellelemente durch Queries liefern k nnen MDA Werkzeuge sollten mit einem eigenen Repository f r die persistente Speiche rung und das Ein bzw Auslesen von Modellen bzw Metamodellen ausgestattet sein Die Verwendung von auf MOF bas erenden Repositories erm glicht den Zugriff auf Meta Modelle die von anderen Werkzeugen erstellt wurden Weiters stellt die Verwendung eines Repositories die Grundlage fur die Durchf hrung eines vern nftigen Versionsmanagements und Mehrbenutzerzugriffs dar M5 OCL Unterst tzung MDA Werkzeuge sollten Unte
152. n Domain Patterns aus Domain Pattern Bibliotheken konstruiert werden Domain Patterns sind immer ap plikations und implementierungsunabhangig Applikations Patterns folgen dem selben Prinzip wie Domain Patterns je doch mit dem Unterschied dass sie auf Applikations Modellebene ange wendet werden und dadurch applikationsabh ngig sind Code Patterns werden auf Code Modellebene verwendet um eine hohe Co dequalit t zu erreichen Es werden zum Beispiel die gesamten Entwurfsmus ter der Gang of Four Gamm96 bei der Generierung von Java Code imple mentiert Kapitel 4 Evaluierung Seite 76 Transformation Functional Model Driven Patterns Patterns Architecture Domain Modell OH Class Service PIM Technology Modell Modell Domain Patterns Patterns Applikations Modell d DBMS EJB Web Annlikati PSM Modell Modell Modell DES aaO Patterns Implementation Patterns Code Modell a Code Code Patterns JSP EJB Jon SQL Klassen Abbildung 4 7 Abstraktionsebenen und Pattern Kategorien in OptimalJ nach CC04 4 3 3 Anpassungsmoglichkeiten von Optimal Compuware erlaubt den AnwendernInnen die Anpassung von OptimalJ durch ihre Optimal Architecture Edition Die Architecture Edition erm glicht die Erstellung und Modifikation von Transformation Patterns und Metamodellen In OptimalJ wird jedes Modell wie z B ein konkretes Geschaftslogik oder Daten bank Modell als Instanz des zugeh rigen Metamodells w e z B Gesc
153. n beispielhafter Auszug aus dem CALENDARIUM Projekt Kapp03 Benutzer der Terminverwaltung sollen ber eine Website Termine anlegen bearbei ten und l schen k nnen Vorraussetzung daf r ist eine erfolgreiche Authentifizie rung der Benutzer Diese funktionalen Anforderungen reichen bereits aus um die wichtigsten Aspekte von Webanwendungen f r d e Fallstudie zu ber cksichtigen Das Anwendungsfalldiagramm in Abbildung 5 1 fasst die funktionalen Anforderun gen an die Webapplikation zusammen Terminverwaltung anmelden abmelden T Termin Benutzer ndern Termin erfas en Abbildung 5 1 funktionale Anforderungen an die Terminverwaltung Jeder Benutzer wird durch einen eindeutigen Benutzernamen identifiziert und besitzt zus tzlich ein Kennwort um sich f r die Anwendung zu authentifizieren Ein Benut zer kann beliebig viele Termine besitzen Ein Termin besteht aus Terminnamen Be ginndatum Beginnzeit Dauer und Ort Das Klassendiagramm in Abbildung 5 2 gibt einen berblick ber die wichtigsten Entit ten der Terminverwaltung Kapitel 5 Fallstudie Seite 112 Termin name beginndatum beginnzeit e dauer beschreibung ort Abbildung 5 2 Entitaten der Terminverwaltung 5 2 Einzusetzende Technologien F r die technische Realisierung der Terminverwaltung ist der Einsatz der J2EE Platt form SUNO3a insbesondere der von Enterprise Java Beans EJB SUNO3b ge fordert Die Architektur der Anwen
154. n die vier Kategorien aufgelistet wobei f r jede Kategorie die wichtigsten Vertreter angef hrt werden 3 3 1 Executable UML Werkzeuge MDA stellt einen sehr abstrakten L sungsvorschlag f r die Entwicklung von Soft waresystemen dar Es werden sozusagen nur d e Rahmenbedingungen vorgegeben die eigentliche Implementierung von MDA Konzepten wird den Toolherstellern zu geteilt Dagegen ist Executable UML em konkreter Vorschlag wie MDA realisiert werden kann Doch Executable UML verwendet nicht die gesamte Spannbreite an MDA Kapitel 3 MDA Werkzeuge Seite 56 Konzepten sondern beschr nkt sich auf die Ebenen PIM und Code Da die Sch pfer von Executable UML die PSM Ebene nur als tempor res Hilfsmodell f r die Erstel lung von Code aus PIM Modellen sehen und da durch den Executable UML Ansatz der gesamte Code einer Anwendung erzeugt wird verzichtet man auf das PSM Konzept zur G nze Es reicht also f r Executable UML Projekte aus ein PIM f r das Softwaresystem zu erstellen Ein Model Compiler transformiert ein Executable UML Modell n eine konkrete Implementierung z B C unter der Verwendung von Informationen ber die Software und Hardwarezielplattformen UML bietet eine einheitliche Notation f r die Repr sentation von unterschiedlichen Aspekten von objektorientierten Systemen Executable UML verwendet eine ausge w hlte Teilmenge der m glichen UML Notationen um ausf hrbare Modelle zu er stellen Ra s04 Defini
155. ndungsf lle modelliert werden und einen ersten Startpunkt der modell getriebenen Softwareerstellung darstellen Dabei sollte sich die Modellierung auf einer abstrakten und berechnungsunabh ngigen Ebene befinden Modellierung MDA r ckt Modelle in das Zentrum des Entwicklungsprozesses und dadurch stellt die Modellierung des Softwaresystems eines der Hauptaufgaben des Entwicklungs prozesses dar Ein Modell sollte alle strukturellen und dynamischen Eigenschaften eines Systems spezifizieren um diese Definitionen durch Transformationen zu ver feinern und auf einer Plattform abzubilden Sind keine Transformationen fur die Ver feinerung des Quellmodells vorhanden m ssen diese erstellt werden Idealerweise sollten die Transformationen modelliert werden und nicht nur in Codeform vorlie gen Somit ist diese Phase in zwei Bereiche aufgeteilt einerseits in die Modellierung des zu erstellenden Systems und andererseits in die Modellierung der benotigten Transformationen Bevor ein Modell durch eine Transformation verfeinert wird soll te das Modell auf die Realisierung der in der Anforderungsphase definierten Anfor derungen durch eine Modellvalidierung berpr ft werden Zus tzlich sollte das Mo dell durch eine Modellverifikation auf formale Fehler untersucht werden Transformation Die durch die EntwicklerInnen erstellten Modelle m ssen weiterverarbeitet werden um plattformspezifische Details einzubringen und schlussendlich den Code f r die An
156. ne riertes Applikations Modell besteht aus folgenden drei Modelltypen o Prdsentations Modell Dieses Modell beinhaltet die fur die Erstellung einer Web Benutzerschnittstelle notwendigen Informationen Durch Wizards konnen EntwicklerInnen das Prasentations Modell durch de klarative Ausdrucke verfeinern Zusatzlich konnen Eingabedaten durch regul re Ausdr cke auf bestimmte Formate validiert werden OptimalJ verwendet das Prasentations Modell um die Kommunikati on mit der BenutzerIn durch JSPs und Servlets zu realisieren o Geschdaftslogik Modell Das Geschaftslogik Modell basiert auf der Enterprise Java Beans Technologie Dieses Modell kann als Abstrak tion f r Enterprise Java Beans Programmcode gesehen werden Op timalJ verwendet das Geschaftslogik Modell um das EJB Modell mit seinen Elementen wie z B Entity Beans oder Session Beans zu erzeu gen Kapitel 4 Evaluierung Seite 73 o Datenbank Modell J2EE Architekturen ben tigen Technologien um persistente Informationen zu archivieren Daf r werden auf Daten bank Modellebene alle ben tigten Datenbankdefinitionen wie z B Tabellen Spalten oder Prim rschl ssel mittels ER Diagrammen spe zifiziert Das Datenbank Modell wird in Optimal f r die Erzeugung von SQL Skripten die f r das Erzeugen bzw L schen von Tabellen und das Bef llen der Tabellen mit Testdaten verantwortlich s nd verwendet Code Modell Diese Ebene definiert die Anwendung durch implementierten
157. ng d h Code zu Modell Transformation m glich ist Die Fallstudie zeigte dass eine Verwendung des ArcStylers nur dann Sinn macht wenn mehrere Projekte mit diesem Werkzeug und ahnlichen Plattformen folgen sol len Wegen der langen Einarbeitungszeit und der m glicherweise selbst zu erstellen den Transformationen ist von einem einmaligen Einsatz eines MDA Werkzeuges abzuraten Kapitel 6 Zusammenfassung und Ausblick 6 1 Zusammenfassung Model Driven Architecture verspricht einen offenen und herstellerneutralen Ansatz f r die Generierung von lauff higen Anwendungen aus plattformunabh ngigen Mo dellen Da der Fokus der Entwicklung auf der Gesch ftsebene liegt sollen Software systeme ohne Wissen ber die einzusetzende Softwareplattform entwickelt werden In den letzten vier Jahren wurden viele Forschungsaktivitaten 1m MDA Bereich un ternommen und einige MDA Werkzeuge konnten sich bereits am Markt behaupten Die Evaluierung der MDA Werkzeuge und die Fallstudie zeigten dass zurzeit nur wenige Vorteile des theoretischen MDA Ansatzes in der Softwareentwicklung prak tisch genutzt werden Im Allgemeinen kann nur der Infrastrukturcode automatisch generiert werden die lauffahige Anwendung jedoch nicht Die Methodenr mpfe der Geschaftslogikmethoden m ssen gro teils von Hand ausprogrammiert werden Von einem anderen Blickwinkel betrachtet entlastet die automatische Generierung des Infrastrukturcodes die EntwicklerInnen und k
158. ngsumstellung bersteigen Nachdem die Kategorien definiert sind wird mit den einzelnen Kategorien und der Definition ihrer zugeh rigen Anforderungen fortgefahren Jede Anforderung erh lt Kapitel 3 MDA Werkzeuge Seite 41 ein eindeutiges K rzel welches sich aus einem Buchstaben und einer laufenden Nummer je Kategorie zusammensetzt Zus tzlich w rd dem K rzel eine sprechende Kurzbezeichnung beigef gt Anhand dieser Beschriftung w rd m Kapitel 4 7 auf die hier folgenden definierten Anforderungen referenziert um eine bersichtliche Werk zeugevaluierung zu gew hrleisten 3 2 1 Modellerstellungskriterien Diese Kategorie besch ftigt sich mit Anforderungen welche f r die Erstellung von rechnerverarbeitungsf higen Modellen erf llt sein sollten um einen positiven Nut zen aus dem MDA Paradigma zu ziehen Um Modelle f r Modelltransformation und oder Codegenerierung einsetzen zu k n nen m ssen diese Modelle zuerst existieren bzw erstellt werden Daf r sollte e n MDA Werkzeug alle Modellierungsaktivit ten in einem Entwicklungsprozess abde cken denn je mehr Informationen in den Modellen enthalten sind desto pr ziser sind die Transformationsregeln anwendbar Weiters sind f r die korrekte Modeller stellung Simulationen und Validierungen wichtige Bestandteile und sollten bei der Erstellung jederzeit anwendbar sein Im Folgenden werden die Anforderungen dieser Kategorie aufgelistet und beschrieben M1 Unterst tz
159. nted out and on the other hand ef fects on the software development process are discussed Further the manual defini tion of transformation rules is explained On the basis of a list of criteria requirements for MDA tools are collected and exist ing tools are examined On the basis of the CALENDARIUM project an example MDA project which uses a relational database Servlets JSPs and EJBs is con structed In this case study a MDA tool s used for the production of an executable application from a platform independent model This case study demonstrates to what extent MDA tools can perform the task auto matically or on which places the programmer still has to do manual programming Further the current state of the art of MDA tools is pointed out by the tool evalua tion On the one hand areas are identified which are already supported by current MDA tools and on the other hand it is shown which areas are covered insufficiently and still need further research activities Inhaltsverzeichnis KAPITEL I EINLEITUNG au 522388 Eee 1 1 1 MOTIVATION TOR MDR eek A l lee MOTIVATION F R DIESE ARBET EE I ET ee 13 E et RE 14 KAPITEL 2 MDA MODEL DRIVEN ARCHITECTURE 000000000000sssssssnssssssssssnnnnnnnnsssnnnnne 16 EE WR EE 16 2 2 MODELLE UND MEIAMODELER eneen geen 19 2 3 NDDA RONZEPTE 435 22 ee een ee 26 KAPITEE 3 VIDA WERKZEU GE E 36 SL MD ASHE NT WICKLUNGSPROZESS Rn anna nlenen 37 3 2 KRITERIENKATALOG F R MDA WE
160. ntifiziert werden n mlich ein externes Modellierungstool die AndroMDA Kern komponente und die MDA Cartridges Wie die Komponenten im Detail aufgebaut sind und welche Aufgaben sie innehaben wird in den n chsten Abschnitten erl utert 4 4 2 Modellierungstool AndroMDA verf gt ber kein integriertes Modellierungstool Daher wird f r die Erstellung der Modelle auf Modellierungstools wie No Magic s Magic Draw oder Gentleware s Poseidon verwiesen In der AndroMDA Dokumentation Andr04 wird Magic Draw als Referenzmodellierungswerkzeug f r das AndroMDA Frame work angegeben und das obwohl es sich bei Magic Draw um em kommerzielles Produkt handelt Gentleware hingegen bietet eine kostenlose Community Edition seines UML Modellierungswerkzeuges Poseidon zum Download an Falls ge w nscht k nnen auch weitere UML Modellierungswerkzeuge verwendet werden l http www magicdraw com Stand 1 1 2005 2 http www gentleware com Stand 1 1 2005 Kapitel 4 Evaluierung Seite 82 nur sollte man darauf achten dass die UML und die XMI Version des UML Modellierungswerkzeuges von AndroMDA unterst tzt werden Zus tzlich m ssen die eingesetzten UML Modellierungswerkzeuge das Anf gen von Stereotypen und Schl sselwort Wert Paaren unterst tzen da diese Informationen f r den Transforma tionsprozess ben tigt werden Um die Modelle f r AndroMDA nutzbar zu machen m ssen diese in eine XMI Date exportiert werden Deshalb ist die
161. odellen Technolo gy Patterns werden in OptimalJ durch sogenannte Incremental Co piers implementiert Incremental Copiers basieren auf der Java Plattform und besitzen ein deklaratives regelbasiertes Format Der Kapitel 4 Evaluierung Seite 75 Ablauf einer Transformation mittels Incremental Copiers kann n zwei Phasen eingeteilt werden Zuerst wird die Struktur des Zielmo dells erstellt danach werden die Werte basierend auf dem Quellmo dell den bereits erzeugten Elementen des Zielmodells hinzugef gt In dieser Diplomarbeit soll aber nicht n her auf dieses Konzept ein gegangen werden F r weitere Informationen und Beispiele wird der Leser auf Kapitel 1 4 4 in CC04c verwiesen o Implementation Patterns werden verwendet um Modelle in Code zu transformieren Angewendet werden sie bei der Transformation von Applikations zu Code Modellen Fur die Erstellung von Implemen tation Patterns wird eine proprietare Skriptsprache Unterkapitel 4 3 3 in OptimalJ geboten Functional Patterns werden auf einer Ebene genutzt Fur die Domain Modellebene werden Domain Patterns fur die Applikations Modellebene werden Applikations Patterns und fur die Code Modellebene werden Code Patterns verwendet Ein Domain Pattern ist ein UML Klassendiagramm das jederzeit wieder verwendet werden kann wie z B ein Klassendiagramm mit den Klassen Kunde Artikel und Warenkorb fur die Spezifikation eines Webshops Ein neues Domain Modell kann anhand vo
162. odellteile und Versionierung sind nur einige wichtige Anforderungen an die Modelldatenbank Da die Hauptinformationen nicht wie be Kapitel 3 MDA Werkzeuge Seite 47 herk mmlichen Softwareprojekten n Dateien vorliegen sondern n Modelldaten banken gespeichert sind erschwert sich die Erf llung dieser Anforderung F r gr ere Projekte mit vielen MitarbeiterInnen wird ein verteilter Modelldaten bankserver notwendig wodurch mehrere EntwicklerInnen gleichzeitig auf verschie dene Modellelemente zugreifen und diese bearbeiten k nnen Haben mehrere Mitar beiterInnen auf die gleichen Modellelemente Zugriff sollte das Tool einen eindeuti gen Authentifikationsmechanismus besitzen um protokollieren zu k nnen wer wel che nderungen am Modell durchgef hrt hat 3 2 2 Modelltransformationskriterien Diese Kategorie besch ftigt sich ausf hrlich mit den Anforderungen an die Modell transformationen Modelltransformationen strukturieren den Artefaktgenerierungs prozess n mehrere Stufen Ohne Modelltransformationen w rden alle notwendigen Transformationsschritte zugleich 1m Codegenerierungsprozess spezifiziert werden der in diesem Fall zu einem u erst komplexen und dadurch auch schwer verwaltba ren Prozess anwachsen w rde Im Folgenden werden die Anforderungen an MDA Tools der Kategorie Modelltransformation aufgelistet und beschrieben T1 Modell zu Modell Transformation OMGO3a definiert mehrere Transformationsarten 1m
163. odeteile werden immer in TPL TPL Blocke eingeschlossen Eine m gliche L sung des vorher besprochenen Beispiels in Bare TPL wird m folgenden Codefragment angegeben TPL TEMPLATE PUBLIC GENERATE _JCLASS String name public class name DI SSES TEMPLATE TPL Bare TPL sollte verwendet werden wenn Leerzeichen pr zise verwaltet wer den sollen Denn nur Leerzeichen innerhalb von Stringdefinitionen werden in die Ausgabedate bertragen hingegen werden Leerzeichen au erhalb von Stringdefinitionen f r die Artefaktgenerierung ignoriert Einen weiteren An wendungspunkt von Bare TPL stellen Skripte dar bei denen ein Gro teil des Skriptes aus TPL Anweisungen bestehen und wenig Skeleton Code vorhan den st da keine besondere Auszeichnung von TPL Anweisungen vorge nommen werden muss e Escaped TPL Die Struktur und Syntax von Escaped TPL unterscheiden sich kaum von denen von Bare TPL Der Unterschied liegt darin dass TPL Kapitel 4 Evaluierung Seite 79 Anweisungen durch eckige Klammern abgegrenzt werden und Skeleton Code ohne besondere Kennzeichnung notiert wird Eine m gliche L sung des vorher besprochenen Beispiels in Escaped TPL wird m folgendem Codefragment angegeben TEMPLATE PUBLIC GENERATE_JCLASS Stringname public class name TEMPLATE Escaped TPL vereinfacht d e Notation von Skeleton Code da z B keine dop pelten Anf hrungszeichen innerhalb des Skeleton Codes
164. ogiespezifi schen MDA Werkzeuge herangezogen da OptimalJ bereits f r mehrere Projekte erfolgreich eingesetzt wurde und bei weitem das ausgereiftere Werkzeug dieser Ka tegorie darstellt 3 3 3 Eigentliche MDA Werkzeuge Zurzeit existiert kein Werkzeug das alle Konzepte der MDA optimal umsetzt Doch einige MDA Werkzeuge unterst tzen durch ausgereifte Modellierungseditoren einen Gro teil der geforderten Konzepte wie z B die Definition von UML Profiles Trans formationen und Metamodellen In den letzten drei Jahren entstanden viele neue MDA Werkzeuge und dieser Trend wird sich auch in der Zukunft aufgrund des immer popul rer werdenden MDA Paradigmas fortsetzen Tabelle 3 4 gibt einen groben berblick ber die aktuell an gebotenen MDA Werkzeuge Kapitel 3 MDA Werkzeuge Seite 61 Toolhersteller Produkt Interactive Objects ArcStyler http www io software com SOFTEAM Objecteering UML http www objecteering com AndroMDA Team AndroMDA http www andromda org open source b m Informatik b m Generator Fra http architecturware sourceforge ne AG open source meWork t site Tabelle 3 4 MDA Werkzeuge Fur die MDA Werkzeugevaluierung n Kapitel 4 werden ArcStyler und Objectee ring UML als kommerzielle Vertreter untersucht Da auch einige Open Source Pro dukte im Bereich MDA Werkzeuge angeboten werden wird als bekanntestes Bei spiel das AndroMDA Framework n her besprochen 3 3 4 Codegeneratoren
165. ol zur Generierung des Work Products sichtbar E n interner Editor siehe Abbildung 4 15 erm glicht die Bearbeitung der er stellten Work Products Reicht einem die Funktionalit t des internen Editors nicht aus so ist es m glich ber Parameterspezifikationen externe Editoren f r die Bearbeitung der Work Products auszuw hlen BEA Tino dino om _ DACVACL fAnal cie _ domationdinaMachinolnn class diagram Update IoIx visualizing the generated file Mel demoVeng Eleme Ee NYAS ONXSSTT J 7 PM operation Lo x Properties Implementation Tagged values namespace ElementsDispensed EQ Ted Drinks Drinks fidet CR_TRACE Name create BAeMDRIS trace_debug 1 Drinks create this T create endif Drinks I destroy amp BY summary Visibility i descripti S i ne A obiecheerng siart eee sa Food name Drinks M Abstract i IA e e le cs sseccossnascssvenzcossevcasseracaet ES l Cannot be specialized ifdef CH CHECK Er IT Class gt l Passing moc Y EEE C in out zu E Diagrams Items C Ki a Editing complete the C Projects cpp ElementsDispensedi Editing the C Projects cpp ElementsDispensed Drinks c Editing complete the C Projects cpp ElementsDispensed B zu Ready Abbildung 4 15 interner Editor des Objecteering UML Modeler Tools Objecteering UML Module werden f r die aktuellsten Plattformen mitgeliefert sie he Tabelle 4 5 oder k nnen
166. ollte die erste Aufgabe in einem MDA Projekt darstellen Das PIM beschreibt alle funktionalen Aspekte der Applikation aber ohne auf plattformspezi fische Details einzugehen Diese werden erst durch eine Transformat on des PIMs n ein PSM eingebracht Diese Transformationen sind gro teils quivalent zu den ber legungen des Programmierers beim Erstellen der Applikation 1 2 Motivation f r diese Arbeit Wie Berichte der sterreichischen Eisenbahnen und der Deutsche Bank Bauspar AG belegen wurden n der Praxis MDA Projekte bereits erfolgreich durchgef hrt De tails zu diesen Projekten findet man auf der OMG Website unter MDA Success Sto ries In diesen Berichten vermitteln die OMG und MDA Werkzeughersteller das Bild dass durch den Einsatz von MDA Werkzeugen einsatzfahige Anwendungen auf Knopfdruck automatisch erzeugt werden k nnen Weiters wird versprochen dass bei der Erstellung von Anwendungen keine Kenntnisse ber Plattformen wie z B Programmiersprachen Betriebsysteme Applikationsserver oder Datenbanken ben tigt werden und dadurch Software auch von Nicht InformatikerInnen entwickelt werden kann In den Berichten werden aber keine Angaben ber relevante Probleme von Modellierungssprachen wie M ngel in der Verhaltensmodellierung von UML oder Transformationssprachen noch keine standardisierte Sprache vorhanden ange f hrt Diese Versprechungen erzeugen hohe Erwartungen bei SoftwareentwicklerInnen und ProjektleiterInne
167. ozesses beschrieben wobei auf m gliche Iterationen nicht eingegan gen wird da primar nur die Aktivit ten und nicht der Ablauf des Prozesses fur die Kriterien von MDA Werkzeugen von Interesse sind Abbildung 3 1 skizziert den vorgeschlagenen MDA Entwicklungsprozess Feedback Initialisierung gt Initialisierung Anforderungs analyse Modellierung Transformation Programmierung Verteilung Test r gt Abbildung 3 1 m glicher MDA Entwicklungsprozess Nat rlich startet ein MDA Projekt wie jedes andere Softwareentwicklungsprojekt auch mit einer Projektinitialisierungsphase Dabei werden meist Projektmanage mentt tigkeiten wie Mitarbeitereinteilung Zeitplanentwurf einzusetzende Techno Kapitel 3 MDA Werkzeuge Seite 38 logien und vieles mehr durchgef hrt In dieser Phase wird der Einsatz eines MDA Werkzeuges zwar noch keinen Sinn ergeben aber diese Phase wird die Entschei dung welches MDA Werkzeug s nnvoll eingesetzt werden kann stark beeinflussen da jedes MDA Werkzeug andere F higkeiten besitzt und unterschiedliche Plattfor men unterst tzt Weiters muss in dieser Phase die Modellierungssprachen die Platt formen des Quell und Zielmodells und die Transformationen identifiziert werden Anforderungsanalyse Mit den ersten berlegungen bez glich der Anforderungen der zu erstellenden Soft ware wird der Einsatz eines MDA Werkzeuges notwendig Die Anforderungen soll ten als Anwe
168. pezifiziert den Template Namen und die bergabeparameter Der Skriptk rper wird wiederum in TPL Anweisungen und Skeleton Code unterteilt TPL Anweisungen dienen der Steuerung des Kontrollflusses z B Schleifen und Bedingungen und der Kommunikation mit der Repository API Skeleton Code Elemente sind vom Modell unabh ngige Textfragmente die in die Ausgabedate geschrieben werden TPL bietet fur die Notation von Skeleton Code und TPL Anweisungen zwei unterschiedliche Konzepte Diese beiden Konzepte werden an hand eines sehr einfach gehaltenen Beispiels erkl rt Dabei soll die Transformation Kapitel 4 Evaluierung Seite 78 einer UML Klasse n Java Source Code definiert werden Es wird aber nur der Name der UML Klasse ber cksichtigt und dem Skript als Parameter bergeben Auf m g liche Attribute oder Methoden wird nicht eingegangen Nehmen wir an die UML Klasse hei t Termin Es soll durch die Transformation folgender Java Source Code erstellt werden public class Termin Im Folgenden werden nun die beiden unterschiedlichen Notationskonzepte anhand des vorher besprochenen Beispiels erkl rt werden e Bare TPL Mittels Bare TPL werden Skeleton Code Bereiche als String Lite rale wie in Java gekennzeichnet Dabei m ssen auch die aus Java bekannten Formatierungsregeln f r Strings beachtet werden TPL Anweisungen werden nicht ausgezeichnet sondern k nnen ohne besondere Markierung m Skript definiert werden Bare TPL C
169. projerebier dar ss Ki Abbildung 4 6 freie und gesch tzte Codebereiche in OptimalJ Da nun die Abstraktionsebenen in OptimalJ ausreichend besprochen wurden k nnen die Transformationen zwischen den einzelnen Ebenen Dom nen zu Applikations modell und Applikations zu Codemodell erl utert werden Da OptimalJ das MDA Paradigma mit dem Einsatz von Patterns Abbildung 4 7 kombiniert werden daher die notwendigen Transformationen mit einem Pattern getriebenen Generierungspro zess durchgef hrt In Optimal werden aber nicht nur f r die Transformationen Pat terns eingesetzt sondern auch f r die Struktur der Modelle Generell kann die Viel zahl an verwendeten Patterns in zwei Hauptkategorien n ml ch in Transformation und Functional Patterns eingeteilt werden e Transformation Patterns werden f r Transformationen zwischen Modellebe nen verwendet Mit ihrer Hilfe werden die Zusammenhange zwischen Ele menten auf Domain und Applikations Modell bzw Applikations und Co de Modell beschrieben Transformation Patterns sind eng mit den definier ten Metamodellen von OptimalJ verbunden da diese die Typen der m gl chen Elemente von Modellen beschreiben Transformation Patterns werden in Technology Patterns und Implementation Patterns unterteilt o Technology Patterns werden verwendet um Modelle in weitere Mo delle zu transformieren Konkrete Anwendung finden sie bei der Transformation von Domain zu Applikations M
170. public sein Document Templates und Generation Templates Die Konzepte Document Templates und Generation Templates beschreiben die zu erzeugenden Arte Kapitel 4 Evaluierung Seite 107 fakte durch die Definition einer hierarchischen Teststruktur Templates sollen den Aufwand der J Programmierung fur Artefaktgenerierung drastisch redu zieren denn jede Zielplattform die ein Textformat besitzt wie z B Java XMI C usw ist durch die Definition von Templates beschreibbar Die Generierung von Dokumentationen stellt einen speziellen Fall von Artefakt generierung dar denn durch spezielle Formate wie z B PDF HTML und die Einbindung von Grafiken der Modelle m ssen erweiterte Anforderungen im Vergleich zu gew hnlicher Textgenerierung ber cksichtigt werden Um weli terf hrende Informationen zur Erstellung von Document Templates zu erhal ten wird auf Soft04f verwiesen 4 7 Evaluierung der Werkzeuge F r die Evaluierung werden Werkzeuge der Kategorien Executeable UML platt formspezifische und eigentliche MDA Werkzeuge welche in den Kapitel 5 1 bis 5 6 beschrieben wurden herangezogen Um der LeserIn einen raschen und aussagekr f tigen berblick ber die Evaluierung der MDA Werkeuge zu verschaffen werden diese in tabellierter Form gegen bergestellt Dabei repr sentieren die Zeilen die An forderungen und die Spalten die evaluierten Werkzeuge Die Produkte werden an hand des m Kapitel 3 2 definierten Kriterienkatalo
171. r t durch die automatische Generierung von EJB Infrastrukturcode aus UML Klassendiagrammen erreicht Mit der kontinuierlichen Verbreitung der modellgetriebenen Softwareerstellung setz ten sich die Entwickler des UML2EJB Projektes ein neues Ziel n mlich die Gene rierung von jeder nur denkbaren Implementierung aus plattformunabh ngigen Mo dellen zu erm glichen Diese Neuorientierung f hrte zu einem neuen Projekt namens AndroMDA Da AndroMDA kein autonomes Werkzeug sondern ein Framework darstellt st tzt sich die Funktionalitat von AndroMDA auf das Zusammenspiel mehrerer Open Source Produkte Einen groben berblick ber die Architektur von AndroMDA zeigt Abbildung 4 8 wobei zwischen dem eigentlichen Codegenerierungsframework und seiner Peripherie externes UML Werkzeug unterschieden wird l http sourceforge net project andromda 2 http sourceforge net projects uml2ejb Kapitel 4 Evaluierung Seite 81 UML Modellierungswerkzeug Magic Draw Poseidon erstellt XMI lt model gt lt class gt lt model gt instanziert AndroMDA Kernkomponente Cartridge Repository EEN Cartridge xml Template Engine Translation Libraries T Metafacades a a Abbildung 4 8 Aufbau des AndroMDA Frameworks In der Abbildung 4 8 k nnen drei Hauptkomponenten des AndroMDA Frameworks ide
172. rbeitungszeit kann die Produktivitat uber das Produktivitatslevel der alteren Technologie gesteigert werden Je kurzer die Kapitel 3 MDA Werkzeuge Seite 53 Zeitspanne der Einarbeitungsphase ist desto schneller amortisieren sich die Investi tionen Ausf hrliche Dokumentationen und angebotene Schulungen s nd ma geblich daran beteiligt die Einarbeitungszeit zu reduzieren Im Folgenden werden die An forderungen der Kategorie konomische Kriterien aufgelistet und n her beleuchtet O1 Anschaffungskosten Die Anschaffungskosten eines Tools sind verglichen mit den laufenden Kosten re lat v einfach zu bestimmen Gerade im MDA Toolsektor werden einige Open Source Produkte kostenlos angeboten dagegen veranschlagen kommerzielle Toolanbieter oft hohe Anschaffungspreise Dieses Kriterium soll dem Leser einen Preisvergleich zwischen den Tools erm glichen und die Spanne zwischen den minimalen und ma ximalen Anschaffungskosten von kommerziellen Tools aufzeigen O2 Unterschiedliche Versionen Um kundenspezifische Anspr che an MDA Tools zu ber cksichtigen sollten vom Toolhersteller verschiedene Versionen angeboten werden welche sich vom Funkti onsumfang und daher auch preislich unterscheiden W hrend einige Software EntwicklerInnen nur Codeskelette aus Modellen ableiten und den Rest manuell programmieren haben s ch andere EntwicklerInnen auf Trans formationen spezialisiert und brauchen daf r erweiterte Toolfunktionen Deshalb so
173. rdware Ap plikationsserver oder Betriebsystem einzugehen Da keine technischen Details ange geben werden beschreibt ein plattformunabh ngiges Modell einen Gesch ftsbereich bzw einen allgemeinen Problembereich S ms04 beschreibt die Vision der OMG wie folgt The clues lie in these key parts of the vision statement separate business from technology enable intellectual property to move away from technology specific 3 code and transform fully specified PIMs on a range of platforms Durch automatische Transformationen ist es m glich PIMs in PSMs berzuf hren Nach erfolgreicher Transformation beschreiben die plattformspezifischen Modelle die Gesch ftsprozesse und das Dom nenwissen in den Konstrukten der gew hlten Softwareplattform Aus einem plattformunabh ngigen Modell k nnen mehrere Imp lementierungen die auf verschiedenartigen Plattformen wie J2EE CORBA oder NET beruhen erstellt werden Die Trennung von plattformunabhangigen und platt formspezifischen Modellen erm glicht die Spezifikation von verschiedenen Prob lembereichen Diese Spezifikationen k nnen bei einem Softwaretechnologiewechsel wiederverwendet werden um neue Applikationen basierend auf der vorhandenen Problemstellung durch automatische Codegenerierung erstellen zu k nnen Weiters befinden sich in den Modellen gen gend Informationen um Tests f r das zu entwi ckelnde System automatisiert zu generieren Da Gesch ftsberei
174. rst tzung f r den Einsatz von OCL als Einschr n kungssprache anbieten Ein weiteres n tzliches Feature w re ein integrierter OCL Editor der automatische Syntax berpr fungen durchf hrt Die im Modell angegebe nen Einschr nkungen sollten in die Transformationen speziell in die Codegenerie rung einflie en Mittels Modellsimulationen sollte eine berpr fungsm glichkeit von Einschr nkungen geboten werden um bereits n fr hen Phasen Fehler n Model len zu finden und zu eliminieren M6 Modellverifikation Fehler in Softwaresystemen sollten 1m Lebenszyklus eines Softwaresystems so fr h wie m glich erkannt werden Idealerweise unterst tzt das MDA Paradigma Fehler erkennung bereits auf Modellebene Somit werden Probleme rechtzeitig erkannt und k nnen kosteng nstiger behoben werden als bei normalen Entwicklungsprozessen Kapitel 3 MDA Werkzeuge Seite 44 Ein sehr effektives Konzept zur fr hen Fehlererkennung stellt die Modellvalidierung dar MDA Werkzeuge sollten f r ihre bereitgestellten Plattformen auch Verifikati onsm glichkeiten ber cksichtigen um der AnwenderIn Feedback ber die Korrekt heit des konstruierten Modells zu geben Zus tzlich sollte das Tool ber Definiti onsm glichkeiten f r eigene Verifikationsregeln verf gen die manuell oder automa tisch ausgef hrt werden M7 Modellsimulation Um Modelle zu simulieren muss zuerst das Verhalten des Systems im Modell fest gelegt werden Deshalb
175. rte Abbildungen eingesetzt werden Dabei definieren Transformationsregeln typbasierte Abbildungen von Modellelementmus ter des Quellmodells in Modellelementmuster eines Zielmodells Zus tzlich k nnen noch Markierungen auf Instanzebene angebracht werden um die Entwurfsoptionen festzulegen Musterbasierte Abbildungen s nd mit Entwurfsmuster vergleichbar je doch enthalten erstgenannte noch zus tzliche Informationen ber den Transformati onsablauf wie z B die Reihenfolge der angewandten Transformationsschritte Quell BEER Quellmodelltypen modell 77 gt ui Muster Transformation Transformations regeln Ziel ee Zielmodelltypen modell 777727 Muster Abbildung 2 11 Musterbasierte Abbildungen nach MDA03 Kapitel 10 3 4 Musterbasierte Abbildungen werden zurzeit in keinem kommerziellen MDA Entwicklungswerkzeug eingesetzt jedoch besch ftigen s ch einige Forschungspro Kapitel 2 Model Driven Architecture Seite 35 jekte mit der Erstellung von auf musterbasierten Abbildungen spezialisierten Trans formationswerkzeugen Realisiert werden die musterbasierten Transformationen durch Graphentransformationsregeln Als Beispiele f r graphenbasierte Transforma tionswerkzeuge siehe GreAT Chri04 UMLX Will03 und BOTL Mars03 Eine ausgezeichnete Einf hrung in Graphtransformationen f r Modelle findet man in Heck00 und Bare02 Transformationen sollten nur bedingt manuell ablaufen im Allgemeinen aber
176. rte von J Attributen werden nicht 1m Modell ge speichert Modulparameter Um die Konfiguration der Profiles durch BenutzerInnen zu erlauben sind Profiles durch Modulparameter parametrisierbar Die Benutze r n kann auf bereits definierte Modulparameter ber das Module Configura tion Fenster zugreifen und so Optionen f r das Modul ausw hlen Zus tzlich kann in J Methoden auf die Werte der Modulparameter zugegriffen werden Dadurch wird die Ber cksichtigung von individuellen Einstellungen f r Arte faktgenerierung Modelltransformationen und vieles mehr m glich Kapitel 4 Evaluierung Seite 106 Work Products Work Products repr sentieren Ergebnisse meistens externe Dateien des Generierungsprozessses die 1m Objecteering UML Modeler aufgerufen werden Als Beispiele fur Work Products konnen Java Quelltexte SQL Skripte oder Dokumentationen angegeben werden Zu einem Work Pro duct k nnen beliebig viele Metaklassen assoziiert werden ber deren Instan zen das Work Product erstellt werden kann Wird eine Instanz einer Meta klasse welche uber Work Products verfugt markiert erscheint ein Icon fur die automatische Erstellung des Work Products Mit Hilfe des Objectee ring UML Profile Builder Tools sind neue Typen von Work Products erstell bar Zu einem Work Product k nnen Metaattribute vom Typ String oder Boo lean hinzugef gt werden Bei der Erstellung eines Work Products im Objec teering UML Modeler werden die Metaattr
177. s Programmierparadigma durchsetzen wird liegt primar in der Hand der OMG und der MDA Werkzeughersteller Werden in naher Zukunft keine konkreten Standards fur Transformationssprachen ausdrucks starke Modellierungsm glichkeiten sowie einheitliche Profiles fur die wichtigsten Softwareplattformen von der OMG ver ffentlicht k nnte MDA einem hnlichen Schicksal erliegen wie die CASE Tools vor einigen Dekaden Zurzeit werden in den MDA Werkzeugen nur proprietare Konzepte der Werkzeughersteller eingesetzt Ausnahmen stellen UML und XMI dar wobei bei XMI unterschiedliche Dialekte eingesetzt werden und so der Modellaustausch zwischen MDA Werkzeugen nicht immer funktioniert Die OMG verspricht durch den Einsatz des MDA Paradigmas enorme Vorteile die nur bedingt durch heutige MDA Werkzeuge erf llt werden Diese Erkenntnis sollte von der OMG st rker kommuniziert werden um keine unerf llbaren Erwartungen bei den EntwicklerInnen zu wecken da die MDA Werkzeuge heute noch keine Technologien darstellen die auf Knopfdruck vollst ndig einsatzfahige Systeme pro duzieren 6 2 Ausblick MDA stellt ein relativ junges und weit reichendes Forschungsgebiet der Informatik dar und kann n der Praxis f r sehr unterschiedliche Projekte eingesetzt werden Da her wurden bei der Durchf hrung dieser Arbeit viele zus tzliche Fragen und Prob lemstellungen aufgeworfen deren Klarung den Rahmen der Arbeit bei weitem Kapitel 6 Zusammenfassung und Ausblick
178. s gute Unterst tzung f r die Entwickle rInnen Neben den Artefakten f r die Applikation werden durch die WLS Cartridge zusatzliche ANT Skripte generiert welche die Erstellung und die Verteilung der einsatzfahigen Archive z B JAR WAR oder EAR vornehmen ArcStyler verf gt uber ein eigenes ANT Fenster Abbildung 5 11 n dem alle verf gbaren ANT Befehle zu einer markierten Komponente angezeigt werden und durch den Benutzer gestartet werden k nnen ohne daf r n die Kommandozeile wechseln zu m ssen Kapitel 5 Fallstudie Seite 133 rd AntTool Build Fies ESSE Ant targets for physical component webapp Description BAELULES H ERA ALOT bd ohos NEIUTE We ALLAL OU resources copy required resources to the webapp director runBrowser start the HTML browser and redirect it to the test server far runCliet runs the default test client runtimeLibs copy required ArcStyler runtime libraries to the webapp dire start Tomcat test server Log lve Abbildung 5 11 ANT Fenster des ArcStylers Verteilung und Test der EJB Applikation Es stehen ANT Skripte f r das Starten der Datenbank und das Anlegen bzw L schen der Tabellen f r die Terminverwaltung zur Verf gung Auch f r das Kompi lieren der EJBs und f r das Packen der kompilierten EJBs zu einem Enterprise Ar chive werden Skripten angeboten Sogar f r das Starten des Applikationsservers und f r die Verteilung des Enterprise Archives werden ANT Skript
179. s logischen EJB Subsystems besser zu verstehen werden zu Beginn dieses Abschnitts die grundlegenden Funktionalit ten der WLS Cartridge aufgelistet Die WLS Cartridge bietet im J2EE Kontext folgende Unterst tzung f r die EntwicklerInnen e Modellierung und Generierung der wichtigsten EJB 2 0 Elemente o Session Beans stateful stateless o Entity Beans Container managed Persistence Bean managed Persis tence o Message driven Beans o Komponentenschnittstellen local remote e Modellierung und Generierung von physischen Paketen Java Archive EJB Archive und Enterprise Application Archive e Unterst tzung f r PointBase und Oracle Datenbanken Kapitel 5 Fallstudie Seite 118 e Erstellung von Projektdateien f r JBuilder und Eclipse e ANT basierte Unterst tzung f r die Erstellung die Tests und die Verteilung der physischen Komponenten Weiters werden von der WLS Cartridge zwei spezielle Typen von UML Diagrammen f r die Modellierung von EJB Applikationen angeboten n mlich das EJB Klassendiagramm und das EJB Komponentendiagramm Beide Diagrammarten sind mit zus tzlichen Funktionen in ihren Men s ausgestattet um h ufig auftretende Arbeitsschritte zu erleichtern bzw zu beschleunigen Fur die persistente Datenhaltung m ssen keine speziellen Diagramme wie z B ER Diagramme erstellt werden da die Datenbankspezifikationen direkt aus dem logi schen Modell des EJB Subsystems abgeleitet werden In Kapitel 5 3 2 w rd auf die
180. setMultiline talse public class _ce Password extends ASTextFieldModel public class _ce Anmelden extends ASButtonModel public class Ge Message extends ASStaticFieldModel Das zweite Codefragment repr sentiert einen Auszug der AnmeldeView Java Server Page In dieser Java Server Page werden die Benuterschnittstellenelemente durch Methodenaufrufe aus dem Objekt me vom Typ AnmeldeView erzeugt Zus tzlich werden Java Script Methoden eingebunden um die Elemente zu formatieren webAccessors anmelden AnmeldeView me webAccessors anmelden AnmeldeView request getAttribute instance lt html gt lt head gt lt title gt lt me getTitle gt lt title gt lt head gt lt 3 start of element root 7 gt lt webAccessors anmelden AnmeldeView _ce_Root root model me getRoot currentModel root__model O lt start of element benutzername gt webAccessors anmelden AnmeldeView ce Boot ce Benutzername root_benutzername__model root__model getBenutzername currentModel root_benutzername__model oe V lt include file amp resources amp jspinc ASLabelForElement ISPILNE lt gt lt include file amp resources amp Jjspinc ASTextField jspinc gt lt 3 start of element password gt lt Ou webAccessors anmelden AnmeldeView ce Root ce Password Kapitel 5 Fallstudie Seite 129 root_password__model root__model getPa
181. sifier Constraint FR Document um P Ca Fei D gt Hz testProject class diaqram 1 HHI Jb Editing the C DOKUME Tiwimsi LOKALE T Temp test_jmethod J file Could not open editor Abbildung 4 16 Hauptansicht des Objecteering UML Profile Builders SOFTEAM f gte Konzepte f r dynamisches Verhalten zu standardkonformen UML Profiles hinzu um die Anforderungen an MDA Kompabilitat zu erf llen Ein Gro teil der Spezifikation des dynamischen Verhaltens wird durch eine propriet re Spra che genannt J realisiert Diese Sprache bietet Unterst tzung f r die Erstellung von Profiles und d e daf r notwendigen Arbeiten auf Metamodellebene Die Sprache J J ist eine Sprache die die Erstellung von UML Profiles im Objecteering UML Profile Builder unterst tzt und d e Parametrisierung und Steuerung des Objecteering UML Modeler erlaubt Die Sprache J ist eine objektorientierte Sprache deren Syntax ahn lich zu der von Java ist J st zur Arbeit auf Metamodellebene und zur Erstellung von UML Profiles konzipiert Da J auf dem Objecteering UML Metamodell entspricht dem UML 1 4 Metamodell basiert bietet diese Sprache spezifische Konzepte um die Verarbeitung der erstellten Modelle und die Navigation zu erleichtern J stellt eine interpretierbare Programmiersprache dar Dadurch k nnen Codefragmente im Objecteering UML Profile Builder rasch modifiziert und getestet werden J wird auf Metamodellebene ausgef
182. spart Nur die Transformation eines plattformunabh ngigen Modells in ein neues plattformspezifisches ist notwen dig um die performanteren Softwareplattformen nutzen zu k nnen Die Erstellung der Transformationen kann entweder firmenintern oder extern durch auf Transforma tionen spezialisierte Unternehmen erfolgen Wiederverwendung basiert auf einer zu feinen Form Eine weitere potentielle Steigerung der Produktivit t im Softwareentwicklungsbe reich basiert auf der Wiederverwendung vorhandener Softwareartefakten Dies wur de in der Informatik schon fr h erkannt und m Laufe der Zeit wurde eine Reihe von Strukturierungsmechanismen entwickelt Im Folgenden werden diese Mechanismen beschrieben Als erste Reaktion wurden Funktionen eingef hrt Somit konnten Programme in Funktionen strukturiert werden und diese Funktionen konnten entweder m selben Programm fters verwendet werden oder in anderen Programmen durch die Erstel lung von Bibliotheken wiederverwendet werden Die Strukturierung von Programmen in Funktionen hat den gro en Vorteil dass n derungen n Funktionen nur einmal und nicht an jeder Stelle wo diese verwendet werden vorgenommen werden m ssen Durch Funktionen wird der Code um einiges bersichtlicher und dadurch auch besser wartbar Doch leider entsteht durch die Kapitel 1 Einleitung Seite 9 Verwendung von Funktionen ein neues Problem Die globalen Datenstrukturen sind mit den Funktionen nicht gekoppe
183. spezifische Details wie Primar schl sseldefinitionen werden erstellt Nat rlich kann das erhaltene PSM durch eine Modell zu Code Transformation in Code ubersetzt werden da im plattformspezifi schen Modell gen gend Informationen zur automatischen Codegenerierung enthalten sind Kapitel 2 Model Driven Architecture Seite 29 entity oa Benutzer ermin PIM benutzername String id ee ud passwort String EntityBean EntityBean Benutzer Termin PSM persistence cmp persistence cmp PK benutzername String PK name String passwort String ort String public interface Benutzer public interface Termin Cod extends EJBObject extends EJBObject ode public interface BenutzerHome Public interface TerminHome extends EJBHome extends EJBHome public class BenutzerBean public class TerminBean implements EntityBean implements EntityBean Abbildung 2 6 Beispielhaftes MDA Projekt Modelltransformationen Allgemein kann eine Modelltransformation als Prozess der Umwandlung eines Mo dells M1 Quellmodell das ein System S1 beschreibt in ein anderes Modell M2 Zielmodell das ebenso ein System S1 beschreibt durch eine Transformation T1 definiert werden Abbildung 2 7 illustriert diese allgemeine Definition einer Modell transformation Kapitel 2 Model Driven Architecture Seite 30 Ouellmodell GEN gt M1 beschreibt beschreibt Z elmodell RE I nn gt M2 Abbildung 2 7 Defin
184. sprachen die Forderung nach einer standardisierten Modellierungssprache fur objektorientierte Systeme st rker Aus dieser Bewegung heraus entwickelte sich die Unified Modeling Language UML die heute in Version 1 5 OMG03b vorliegt Im Jahr 2001 wurde ein weiteres Fra mework von der OMG ver ffentlicht n mlich die Model Driven Architecture MDA OMGO01 OMG03a Im Gegensatz zu OMA oder CORBA welche nur auf Kapitel 2 Model Driven Architecture Seite 17 verteilte Systeme ausgerichtet sind fokussiert MDA auf die modellgetriebene Ent wicklung von Softwaresystemen Im Folgenden wird anhand des Logos von MDA Abbildung 2 1 ein berblick ber die Grundlagen von MDA gegeben Finance Manufacturing E Commerce Space d a var Telecom Transportation HealthCare More Abbildung 2 1 MDA Logo Das Logo kann grob in vier Bereiche eingeteilt werden Der innerste Kreis des Lo gos listet die wichtigsten Technologien f r die Modellierung von Softwaresystemen auf Diese sind Unified Modeling Language UML Meta Object Facility MOF OMG02c Common Warehouse Model CWM OMG03c Diese Technologien stellen bereits existierende OMG Standards dar UML wird fur die Modellierung von Struktur und Verhalten von Systemen eingesetzt und bietet daf r unterschiedliche Diagrammarten wie Klassen Aktivitats Sequenzdiagramme und noch viele mehr Fur die Modellierung von Metasprachen z B UML wird MOF eingesetzt Weiters sind S
185. ssword currentModel root_password__model ie vV lt include file amp resources amp jspinc ASLabelForElement sp ne lt gt lt include file amp resources amp Jjspinc ASTextField jspinc gt lt start of element anmelden gt lt webAccessors anmelden AnmeldeView ce Root ce Anmelden root_anmelden__model root__model getAnmelden currentModel root_anmelden__model oo gt lt include file amp resources amp jspinc ASButton jspinc gt ie lt start of element message gt N ie webAccessors anmelden AnmeldeView _ce_Root _ce_Message root_message__model root__model getMessage currentModel root_message__model ie V lt include file amp resources amp jspinc ASLabelForElement Ispiner lt gt lt include file amp resources amp jspinc ASStaticField jspinc gt lt end of element root 3 gt lt body gt lt html gt 5 3 3 Erg nzung des generierten Codes Dieses Unterkapitel besch ftigt sich mit der manuellen Codeerg nzung der generier ten Artefakte ArcStyler bietet nicht f r jeden Bereich 100 Codegenerierung und somit m ssen einige Codeteile von den ProgrammiererInnen h ndisch erstellt wer den F r das Arbeiten auf Codeebene empfiehlt sich die Nutzung der automatischen Erstellungsfunktion von Projektdateien f r Eclipse oder JBuilder da eine Program mier IDE eine gro e Hilfe f r die manuelle Codeerg nzung darst
186. stenlos beziehbar ber http www eclipse org gef Stand 1 1 2005 3 kostenlos beziehbar ber http www eclipse org uml2 Stand 1 1 2005 Kapitel 3 MDA Werkzeuge Seite 62 basierend auf EMF Leider wird durch das UML2 Project nur das Metamodell reali stert ein grafischer Editor jedoch nicht Zur Zeit werden Codegeneratoren basierend auf diesen Frameworks angeboten die aus UML Klassendiagrammen einige Klassendefinitionen ableiten aber keine MDA Konzepte umsetzen Jedoch besitzen diese Frameworks und die Eclipse Plattform ein enormes Potential fur die Entwicklung von MDA Werkzeugen durch Plugins In dieser Arbeit werden Werkzeuge der Kategorie Codegeneratoren nicht naher un tersucht da diese keine MDA Konzepte implementieren und nur begrenzt zur Code generierung bzw zur modellgetriebenen Softwareentwicklung eingesetzt werden k nnen Deshalb wird auch kein Werkzeug dieser Kategorie im Kapitel 4 evaluiert Kapitel 4 Evaluierung Die wichtigsten Vertreter der im Kapitel 3 3 definierten Werkzeugkategorien werden in diesem Kapitel genauer beschrieben F r den Executable UML Werkzeugbereich werden Nucleus BridgePoint Development Suite Unterkapitel 4 1 und IUML ICCG Unterkapitel 4 2 ausgew hlt Im Bereich technologiespezifische Werkzeuge wird Optimal Unterkapitel 4 3 detailliert besprochen Als Vertreter der eigentlichen MDA Werkzeuge werden ArcStyler Unterkapitel 4 5 und Objecteering UML Un terkapitel 4 6 als kommerzi
187. ter MDA verstanden wird Somit war Objecteering UML eines der ersten Tools fur modellgetriebene Entwicklung am Softwaremarkt und ein Pionier fur alle heute erhaltlichen MDA Werkzeuge Objecteering UML entwickelte sich ber die letzten zehn Jahre vom UML CASE Tool zu einem MDA Tool das den gesamten Entwicklungsprozess von der Analyse bus zur Artefakterstellung abdeckt Es werden Versionen f r Windows Linux und Solaris angeboten wobei je vier unterschiedlich umfangreiche Pakete erh ltlich sind Die Spanne reicht vom einfachen UML Modellierungseditor bis hin zum mehrbenut zerfahigen MDA Tool F r die Evaluation wird Objecteering UML Enterprise Editi on Version 5 3 0 fur Windows eingesetzt Als minimale Konfiguration fur Projekte mit kleinen Modelldatenbanken bis unge fahr 10 MB Speicherplatz werden 1 GHz Prozessorleistung 512 MB Arbeitsspei cher und 300 MB freier Festplattenspeicherplatz genannt Die empfohlene Konfigu ration fur Projekte mit groBen Modelldatenbanken wird mit mindestens 1 GHz Pro zessorleistung 2 GB Arbeitsspeicher und 600 MB freiem Festplattenspeicher ange geben Die Funktionalitat von Objecteering wird durch zwei eigenstandige Softwarekompo nenten siehe Abbildung 4 13 realisiert e Objecteering UML Modeler wird von SoftwareentwicklerInnen wie Soft waredesignerInnen und ProgrammiererInnen verwendet um Softwaresyste me zu modellieren e Objecteering UML Profile Builder wird von Softwarequalitatssic
188. terface Modellierung F r heutige Applikationen stellt em ausgereiftes User Interface ein notwendiges Fea ture dar Daher sollten MDA Werkzeuge eine M glichkeit bieten Benutzerschnitt Kapitel 3 MDA Werkzeuge Seite 45 stellen zu modellieren oder zumindest in einer proprietaren Form zu definieren Eine abstrakte Spezifikation der Benutzerschnittstelle durch Modelle w rde die automati sche Erstellung von mehreren Varianten von User Interfaces Implementierungen erm glichen Somit w ren JSPs f r em Webinterface oder Swing Klassen f r eine Applikation aus dem Modell ableitbar Standardm ig bietet UML keine Modellierungsm glichkeit von User Interfaces aber UML Profiles f r User Interface Definitionen k nnten n naher Zukunft real siert werden Bis dahin k nnten Tools spezielle Metamodelle f r den User Interface Entwurf verwenden oder den Zugriff auf die modellierten Komponenten aus exter nen User Interface Erstellungstools wie z B MacroMedia DreamWeaver ermogli chen M10 Unterst tzung von abstrakten konkreten Plattformen Damit plattformunabhangig modelliert werden kann sollten abstrakte Plattformkon zepte wie z B Objekte oder Komponenten standardm ig unterst tzt werden Dies wird bereits haupts chlich durch UML 1 x bzw UML 2 0 Diagrammarten abge deckt Um die effiziente Erstellung von Softwaresystemen zu f rdern sollten MDA Tools die aktuellsten Technologien wie EJB Net oder CORBA unterst tzen um
189. tml Anhang B Code der Terminverwaltung B 1 B 2 B 4 generierte Codeteile des EJB Systems siehe CDROM gen wsl8_gen generierte Codeteile des Web Systems siehe CDROM gen webacc_gen lauff hige EJB Komponente siehe CDROM magister gen components libs ejbsDefaultServerApplication wls8 ejbsDefaultServerApplication ear lauff hige Web Komponente siehe CDROM magister magister gen components libs webapp webapp war Installationsanleitung siehe CDROM readme pdf Abbildungsverzeichnis Abbildung 1 1 Modell Transformation PIM gt DaM 3 Abbildung 1 2 Programmiersprachen Abstraktionsschritte basierend auf Mell04 5 Abbildung 1 3 Webshop Klassendiagramm ssssnsnnnssssneeeeeeeeeeeeeeennnnnnnnn 6 Abbildung 1 4 zeitliche Entwicklung von aktuellen Plattformen 8 Abbildung 1 5 Wiederverwendungspotential von Software 10 Abbildung 2 15 MID AVG G0 elek 17 Abbildung 2 2 Definition und Aufgabe von Modellen 20 Abbildung 2 3 Metamodellieruns sde Sege aset gege 23 Abbildung 2 4 Sprachen und Metasprachen 00000sonononnnnnnnnsnnnnsssssssssssseeerrrresessssse 24 Abbildung 2 5 Metamodellhierarchie der OMC 26 Abbildung 2 6 Beispielhaftes MIDA Droiekt cc cecesesseseeeeeeececeeeeesesauaeeeeeeeeeeees 29 Abbildung 2 7 Definition von Modelltransformationen sssoeoeeeeeeeneeeeeeeseeeeseseses 30 Abbildung 2 8 mehrstufiger Transtormatonsprozessg 30 Abbildung 2 9 Typbasi
190. tsintensiv und dadurch auch teuer da ein Gro teil der Arbeitsschritte nicht automatisiert abl uft sondern von den ProgrammiererInnen h ndisch durchgef hrt werden muss Mit jeder Einf hrung von neuen Softwaretechnologien entstehen Modifikationen an bestehenden Softwaresys temen Bei gravierenden Umstellungen der Technologien bleibt eine Re Implementierung der Softwaresysteme nicht aus und eine Umschulung des Personals stellt ein Muss f r em erfolgreiches Projekt dar Weiters ben tigt ein nicht triviales Softwaresystem f r die Erf llung seiner Aufgaben mehrere verschiedene Technolo gien und kommuniziert ber Netzwerke wie z B das Internet mit anderen Syste men Um eine effiziente Nutzung einer Applikation zu erreichen wird eine Vielzahl der heute entwickelten Applikationen als verteilte Systeme d h ber mehrere Rech ner verteilt ablaufend entworfen Kapitel 1 Einleitung Seite 2 Die erw hnten Entwicklungen fordern neue Entwicklungsmethoden um die Erstel lung von Software zu erleichtern bzw zu automatisieren Diese Erkenntnis st bei weitem keine neue denn Dijkstra D1Jk 72 bemerkte bereits im Jahr 1972 Ihe art of programming is the art of organising complexity Trotz Verbesserungen in Softwareentwicklungsprozessen und Programmiertechni ken befindet sich die Produktivit t 1m Bereich Softwareentwicklung immer noch auf einem zu niedrigen Niveau Mell04 erkl rt daf r folgende Gr nde welche auf M ngel
191. twareprojekt von einem gewohnli chen Softwareprojekt Die Hauptforschungsfragen dieser Diplomarbeit sind einerseits die Erstellung eines Kriterienkataloges f r die Evaluierung von MDA Werkzeugen und andererseits die Eruierung des aktuellen technischen Stands der Werkzeuge Dabe soll untersucht werden ob und w e sich MDA Werkzeuge von gew hnlichen Codegeneratoren un terscheiden Kapitel l Einleitung Seite 14 1 4 Aufbau In dieser Diplomarbeit wird ein fundierter berblick ber die Grundlagen und die theoretischen Konzepte von Model Driven Architecture gegeben Diese Aufgabe n mmt die erste H lfte der Arbeit ein Der zweite Teil der Arbeit besch ftigt sich mit dem praktischen Einsatz des MDA Paradigmas in der Softwareentwicklung Dabei werden MDA Werkzeuge anhand eines Kriterienkataloges besprochen Abschlie Bend wird der heutige technische Stand der Werkzeuge anhand des Fallbeispiels CALENDARIUM bestimmt Im Folgenden wird ein berblick ber die Kapitel die ser Arbeit und deren Inhalt gegeben Das zweite Kapitel besch ftigt sich mit den Grundlagen von Model Driven Architec ture Dem Leser wird ein berblick ber Konzepte wie Modelle Metamodelle Transformationen sowie den grunds tzlichen Aufbau des MDA Paradigmas geboten Zus tzlich werden die Vorteile des Einsatzes von Softwaremodellen besprochen Da MDA keine Technologie im engeren Sinne darstellt werden die einsetzbaren Me tamodelle wie UML oder CWM
192. uced into software development practice MDA is seen as the next step in the formalizing and abstraction process of software like the replacement of assembler by high level languages If we believe in the promises of the OMG then full working applications for different software platforms e g JZEE NEI CORBA can be automatically generated from platform independ ent models The OMG defines a theoretical architecture and specification of MDA but the im plementations of tools and transformation rules are transferred to the software indus try Tool manufacturers should develop MDA tools which support model transfor mations and further aid for the successful employment of MDA in practical software development In practice several projects were already realized with MDA support on basis of al ready existing tools The vision of the OMG 1s that applications are automatically generated from models Here it has to be clarified whether the tools really implement MDA concepts or whether they are no more than UML tools which can derive code segments automatically from graphical models This diploma thesis describes in detail the theoretical concepts of MDA as well as the practical MDA aspects on the basis of the CALENDARIUM project The theo retical concepts like platform independent models platform dependent models model transformations and metamodels are explained On the one hand problems of the transformation of the different models are poi
193. ung von UML 1 x 2 0 UML wird als Kernmodellierungssprache f r die modellgetriebene Softwareentwick lung gesehen da UML zurzeit die meiste Verwendung in Softwareprojekten findet EntwicklerInnen und ArchitektInnen sind mit UML vertraut und haben diese Spra che bereits in bisherigen Softwareprojekten f r Dokumentationen und Anforde rungsanalysen eingesetzt Um dem Anspruch an MDA Unterstutzung gerecht zu werden sollte em MDA Tool standardm ig d e Erstellung von UML Diagrammen unterst tzen d h es sollte der AnwenderIn das gesamte Spektrum von Struktur und Verhaltensdiagrammen zur Verf gung stehen Weiters sollten die Notationselemente mit UML standardkonfor mer Syntax m Tool angeboten werden Leider war n bisherigen UML CASE Tools die Syntax der Notationselemente leicht ver ndert oder es gab zus tzliche nicht UML konforme Notationselemente bzw wurden einige Standardnotationselemente berhaupt n cht unterst tzt Kapitel 3 MDA Werkzeuge Seite 42 Mit der Entstehung des MDA Paradigmas wurde das Bed rfnis nach einer aus drucksst rkeren und auf Metaebene bzw Metametaebene konsistenteren Modellie rungssprache als UML 1 x erkannt Die OMG reagierte mit der Standardisierung einer neuen UML Version UML 2 0 die zurzeit als OMG Adopted Version OMG03f vorliegt Da der Standard noch nicht in der finalen Version festgelegt wurde warten noch viele Toolanbieter mit der Implementierung der Version 2 0 in ihrem Produkt ab
194. ution Data Breakpoints Stimulus Tools Help Class Status leee 1 gt define instance function TL1 Display_Traffic_Light A 2 instance this Traffic_Light 3 input N 4 red_light Text 5 amber_light Text 6 green_light Text 7 output Forward the request to the display unit Cancel Signal Queue Queue Priority Signal Status 1 1 Consume A Consume 3 1 Consume A 1 Consume 5 1 Mnnecume lt gt Cancel Starting application X_TLS exe A aiting for application to respond Local Variables X_TLS exe has started S Ste Variable Name Tvoe Val Stopped Domain TLS Initialisation Segment 2 Line 2 this Instance DEF ee red liaht Text On stopped Domain TLS Class Traffic_Light State 2 Line 1 Signal TL1 Busy esin _ lamber liaht Text Off Stopped Domain TLS Class Traffic_Light State 2 Line 1 Signal TL1 areen liaht Text Off ERR i Dec road Instance UN stopped Domain TLS Class Traffic_Light State 2 Line 3 Signal TL1 ein L gt Stopped Domain TLS Operation TL1 Display_Traffic_Light Line 1 Cancel Abbildung 4 4 Benutzeroberfl che des 1 UML Simulators road this gt Rl 11 DUl Display_Traffic_Light 5N 12 this traffic_light_number 13 road road_name N 14 red_light 15 amber_light N 4 2 2 iCCG ICCG stellt ein Codegenerierungsframework dar das den EntwicklerInnen die Ent
195. wareplattform gefordert sind wie z B Wissen uber die Eigen schaften der Methode getEJBRef EjbCalendarium_anmelden_Benutzer public boolean authentifizieren java lang String benutzer java lang String password START OF PROTECTED AREA lt lt authentifizieren eringsscring gt gt 7y insert custom code here BenutzerHome benutzerHome this getEJBRef_EjbCalendarium _anmelden_Benutzer Benutzer theBenutzer null try theBenutzer Benutzer benutzerHome findByPrimaryKey benutzer catch Exception eil E if theBenutzer null amp amp password equals theBenutzer getPassword rerurn truc Benutzername Passwortkombination II KOTrekt catch java rmi RemoteException re return false Jk END OF PROTECTED AREA 1604e74e0000006e C In den Controller Klassen des Web Subsystems s nd weitere Codeerg nzungen not wendig Das Verhalten der Controller Klassen wird durch hre Accessor Aktivitatsdiagramme definiert In den Accessor Aktivit tsdiagrammen sind nur die Deklarationen der Methoden f r Zust nde und Zustands berg nge definierbar nicht aber die konkreten Aktionen der Methoden Diese Aktionen k nnen erst auf Code ebene spezifiziert werden da ArcStyler keine Definitionsm glichkeiten von Aktio nen auf Modellebene anbietet Kapitel 5 Fallstudie Seite 131 Als Beispiel f r die Codeerganzungsarbeiten im Controller Bereich soll die Imple mentierung der Methode checkLogin
196. wendung zu generieren Daf r m ssen in dieser Phase zwei Transformationsarten angewandt werden Einerseits sollten Modell zu Modell Transformationen f r die automatische Erstellung von konkreteren und detailreicheren Modellen durchgef hrt Kapitel 3 MDA Werkzeuge Seite 39 werden und andererseits Modell zu Code Transformationen f r d e Erstellung der Artefakte angewandt werden Programmierung Der von MDA Werkzeugen automatisch generierte Code stellt im Allgemeinen noch keine einsatzfahige Anwendung dar Die EntwicklerInnen m ssen noch die Ge schaftslogikmethoden ausprogrammieren da die meisten MDA Werkzeuge keine automatische Generierung von Geschaftslogik anbieten In dieser Phase m ssen auch Testskripte erstellt bzw erganzt werden da diese durch die heutigen Technologien nicht komplett aus den Modellen abgeleitet werden Verteilung Test Die letzte Phase des Softwareentwicklungsprozesses stellt die Verteilung und den Test der Applikation dar Die einsatzfahigen Komponenten mussen auf verschiedene Maschinen verteilt und konfiguriert werden M glicherweise m ssen die neuen Komponenten n vorhandene Systeme Legacy Systeme integriert werden Die Funktionalit t der neuen Komponenten und das Zusammenspiel mit vorhandenen Systemen muss schlie lich noch durch Tests berpr ft werden MDA bietet auch f r die Verteilung und f r das Testen der Applikation Unterst t zung f r die EntwicklerInnen Auf Modellebene k nnen Testf
197. wicklung von eigenen Transformationen Executable UML Modelle zu Code oder die Anpassung von vorhanden Transformationen erlaubt Die Transformationen wer den in ASL verfasst und basieren auf dem Metamodell von Executable UML In Kapitel 4 Evaluierung Seite 70 FORMAT Blocke siehe Abbildung 4 5 ist es m glich Skeleton Code f r die zu generierenden Dateien n ASL zu definieren ICCG verf gt ber einen eigenen Co degenerator der die in ASL geschriebenen Transformationsregeln aufnimmt und daraus einen Transformationsgenerator f r das eigene Projekt generiert Dieser ICCG Codegenerator stellt ein zu CompilerCompiler hnliches Konzept dar Der Codegenerator f r das eigene Projekt ist eine ausf hrbare Datei die im IUML Mode ler erstellte Executable UML Modelle in Code transformiert Abbildung 4 5 ver deutlicht das eben erkl rte Konzept des ICCG Codegenerierungsframeworks allClasses find all Class for class in allClasses do SFORMAT code_file public Class T class name SENDFORMAT Attribute attributes class gt R3 for attribute in attributes do SFORMAT code_file SENDFORMAT Executable UML Metamodell endfor endfor Tranformationen in ASL iCCG Code Generator ee Kunde Bestellung Project gt code gt name String nummer int Generator eg Executable UML Modell Java Code Abbildung 4 5 iCCG Codegenerierungsfra
198. wird in OptimalJ eine Applikation in drei unter schiedlichen Abstraktionsebenen erstellt Dabe1 werden die Ebenen aquivalent zum Kapitel 4 Evaluierung Seite 72 MDA Paradigma eingeteilt aber OptimalJ bezeichnet die Ebenen mit eigenen Na men Im Folgenden werden die drei Abstraktionsebenen von Modellen in OptimalJ aufgelistet und beschrieben Domain Modell Auf dieser Ebene werden fachliche Modelle erstellt die die Struktur und das Verhalten der zu entwickelnden Systeme plattformunab h ngig d h ohne auf Technologiedetails einzugehen beschreiben Das Do main Modell entspricht dem PIM des MDA Paradigmas Die Domain Modellebene wird in zwei Unterkategorien Domain Class Modell und Do main Service Modell eingeteilt Das Domain Class Modell beschreibt durch den Einsatz von Klassendiagrammen die statische Struktur der Applikation Das Domain Service Modell beschreibt die Verhaltensaspekte der Anwen dung Durch das Domain Service Modell wird aber nur das Verhalten fur Create Update Delete der Entitaten abgedeckt Applikations Modell Diese Ebene definiert die Applikationsarchitektur ba sierend auf der J2EE Plattform aber ohne auf Details der Programmierung einzugehen Das Applikations Modell liegt zwischen dem abstrakten Do main Modell und dem konkreten Code Modell Das Applikations Modell beschreibt welche Elemente generiert werden mussen um eine einsatzfahi ge J2EE Applikation zu implementieren Ein aus dem Domain Modell ge
199. wortfeld ben tigt so ist em m hsames Suchen im Quelltext der mitgelieferten Beispielanwendungen notwendig Fur ein effektives Arbeiten mit dem ArcStyler Tool muss eine lange Einar beitungszeit in Kauf genommen werden denn EntwicklerInnen m ssen eine neue Form der Programmierung erlernen Kapitel 5 Fallstudie Seite 136 ArcStyler verwendet propriet re Metamodelle f r die WLS Cartridge und die WebAccessors Cartridge Dieses Faktum macht die Nutzung der erstell ten Modelle m anderen MDA Werkzeugen unm glich Der generierte Code ist anfangs schwer verst ndlich In den Klassen der Controller und Viewschicht werden viele innere Klassen definiert und der Aufbau der JSPs ist anfangs auch schwer zu durchschauen Weiters sei noch auf die ineffizienten SQL Skripten hingewiesen Beispielsweise werden die Felder f r Attribute vom Datentyp String wie z B das Passwort eines Be nutzers standardm ig als VARCHAR 2000 angelegt Diese Felder k n nen und sollten im ArcStyler ber die Markierungsfenster genauer spezifi ziert werden Treten beim Testen der Applikation Fehler auf ist es f r die EntwicklerIn sehr schwer zu entscheiden ob man diese auf Modellebene beheben soll bzw kann oder ob diese Fehler nur auf Codeebene beseitigt werden k nnen In diesem Zusammenhang w re es weiter interessant zu kl ren inwieweit ArcStyler manuelle Codeerg nzungen ins Modell aufnehmen kann bzw ob und in welchem Umfang ein Reverse Engineeri
200. zu den Anforderungen dar und vice versa Die Anwendungsf lle sollten am Beginn des Entwicklungsprozesses als erster Ankn pfungspunkt f r weitere Modellierungsschritte fungieren M13 Modellierung von Testf llen Da im MDA Paradigma Modelle die Basis f r den generierten Code darstellen ist es n tzlich d e Testf lle aus den Modellen abzuleiten und diese ebenso zu modellieren Dadurch wird auch die automatische Codegenerierung f r Testf lle m glich Ein MDA Tool sollte somit d e Definition und das Management von einzelnen Testf llen bzw von gesamten Testsuiten unterst tzen Es existieren mehrere Metamodelle fur die Modellierung von Testspezifikationen wie z B Testing and Test Control Notation TTCN ITU03 Da diese aber nicht auf MOF bas eren und hre eigenen Diagrammnotationen verwenden werden eigene Tools f r hren Einsatz ben tigt Eine L sung w ren Integrationsm glichkeiten n einem MDA Werkzeug oder der Aufbau eines MDA Frameworks das die Nutzung der auf Tests spezialisierten Tools erm glicht UML Profiles fur Testspezifikationen k nnten weitere Erleichterungen f r die Testerstellung und Verwaltung mit sich bringen M14 Mehrbenutzerf higkeit Abgesehen von kleinen Projekten mit geringem Personaleinsatz stellt Modellierung wie die Softwareentwicklung 1m Allgemeinen eine Teamaktivitat dar Deshalb soll ten MDA Werkzeuge mehrbenutzerf hig ausgerichtet sein Gleichzeitiger Mehrbe nutzerzugriff auf gleiche M

Papers - Business Informatics Group

Contents

Download Pdf Manuals

Related Search

Related Contents