Using openArchitectureWare 4.0 in domain "registration"

Das Forschungs- und Entwicklungsprojekt OrViA wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) gefördert, die innerhalb der zweiten Auswahlrunde der Forschungsoffensive „Softwareengineering 2006“ vergeben wurden, und vom Deutschen Zentrum für Luft- und Raumfahrt (DLR), Projektträger Informationstechnik/ Softwaresysteme betreut.

Institut für Informatik Betriebliche Informationssysteme

1

openArchitectureWare 4.0 Endpräsentation

Jörg Reichert


© Universität Leipzig 2006 2

Gliederung

1. Einführung 2. Begriffe 3. Vorgehensprinzipien 4. openArchitectureWare 5. Praxis-Beispiel mit openArchitectureWare 6. Fazit



Einführung

• Modellgetriebene Softwareentwicklung • Motivation und Ziele • Entstehungsgeschichte • Abgrenzung des MDSD- vom MDA-Ansatz



Modellgetriebene Softwareentwicklung

Definition Modellgetriebene Softwareentwicklung ([MDSD*05], S. 16): • Software wird ganz oder teilweise aus Modellen generiert • Modelle haben nicht mehr allein die Aufgabe der Dokumentation sondern werden Bestandteil der Software • Modelle werden mit Programmcode gleichwertig gestellt, da aus ihnen der Hauptanteil des Zielprogramms generiert werden

kann

Definition Plattformunabhängiges Modell (PIM) ([MDSD*05], S. 18): • Modell, welches technologieunabhänigig den Problemraum beschreibt • den modellierten Elementen werden Rollen zugewiesen, die im plattformspezi-fischen Modell aufgegriffen werden (z.B.

umgesetzt mit UML-Profiles)

Definition Plattformspezifisches Modell (PSM) ([MDSD*05, S.18): • Modell, das die Umsetzung der Domäne auf einer konkreten Plattform beschreibt • durch Modell-zu-Modell-Transformationen lassen sich PIMs in die jeweiligen PSMs überführen • den modellierten Elementen werden nun plattformspezifischen Rollen zugewiesen, die von den Rollen aus dem PIM abgeleitet

sind (wiederum UML-Profile einsetzbar)



Motivation und Ziele

Motivation • schnellere Entwicklungszeiten (Time-2-Market) und geringe Kosten • schnelle und gute Reaktion auf häufige Änderungen der Fachanforderungen • Vereinfachung der Variantenbildung (Funktionsumfang, Zielplattform) Bildung von Software-Systemfamilien • Qualitätssteigerung

Ziele • bessere Integration von Fach- und IT-Abteilung • Aufbau etablierter Konzepte, die wiederverwendet werden können • verstärkte Automatisierung des Entwicklungsprozesses • Fehlerreduzierung Umsetzung • gemeinsame Diskussions-Grundlage in Form der in der DSL formulierten Modelle • Änderungen in den Modellen werden konsistent an Generate weitergegeben • einmal definierte Constraints prüfen Generate und abgeleitete Modelle bei jeder Änderung an den Ausgangsmodellen



Entstehungsgeschichte

Historische Entwicklung ([MDSD*05], S. 12): • Anfang der 90-er Jahre waren die verschiedenen CASE-Methoden (Computer Aided Software Engineering) nebst

entsprechenden CASE-Werkzeugen sowie die Sprachen der 4. Generation weder ausgereift noch ausreichend standardisiert um sich durchsetzen zu können

• Mitte und Ende der 90-er Jahre: Aufkommen objektorientierter Sprachen sowie entsprechenden Modellierungsmethoden und -werkzeugen, als bedeutendste Entwicklung der Notationsstandard UML

• UML wurde anfänglich nur als Dokumentation des Codes verwendet und hatte nur spärliche Codegenerierungsfunktionalität • Heutzutage enthalten viele integrierte Entwicklungsumgebungen (IDEs) UML-Modellierungswerkzeuge, die auch in der Lage

sind, komplexen Code zu generieren, Änderungen am Fachkonzept können sie allerdings noch nicht an den gesamten Programmcode schrittweise weiterpropagieren

• aus diesen Problemen resultierte die MDA-Initiative der OMG, die die Entwicklung von Werkzeugen voran treibt, mit denen man genau festlegen kann, wie UML-Modelle auf die einzelnen Bestandteile der Implementierung abzubilden sind



Abgrenzung des MDSD- vom MDA-Ansatz

• Markus Völter [Völt05] sieht Model-Driven Architecture (MDA) als Spezialisierung des Model-Driven Software-Development (MDSD) Ansatzes, da MDA festlegt dass alle DSLs mit MOF (Meta Object Facility, Metamodell der UML, von der OMG spezifiziert) definiert werden

müssen (in der Praxis werden meist UML-Profile mit Tagged Values verwendet) dass Metametamodelle mit MOF definiert werden müssen dass Transformationen dem QVT (Query, Views, Transformations)-Prinzip folgen müssen dagegen soll in der MDSD offen sein, womit Metamodelle und DSL sowie die auf ihnen ausgeführten Transformationen beschrieben werden

• Hauptanliegen der MDA ist, dass die gleiche Anwendungslogik auf mehrere Plattformen übertragbar sein soll, daher stellen MDA-Tools wie androMDA (http://www.androMDA.org) Cartridges (zu deutsch: Steckmodule) für technische Plattformen wie Hibernate, Spring, BPM4Struts, Java, EJB, JSF, jBPM, Meta, WebServices und XML-Schema bereit

• MDSD-Ziele sind dagegen weiter gefasst: neben Steckmodulen für einzelne technische Umsetzungsvarianten sollen auch der Entwurf und die Verwendung von Fach-Domänen-Cartridges unterstützt werden

• solche Cartridges bereits vordefiniert auszuliefern ist allerdings schwierig, da die Vielfalt deutlich höher als auf technischer Ebene ist, wo man mit wenigen Stereotypen, wie z.B. Entität und Service sowie deren Umsetzungsvarianten EJB Entity Beans, POJO und EJB Session Bean und Spring, auskommen kann

http://www.andromda.org/



Begriffe

• Modellierung und DSL • Plattform und Transformation • Domänenarchitektur



Modellierung und DSL (1)

Definition Domäne ([MDSD*05], S. 66): • begrenztes Wissens- bzw. Interessensgebiet • unterteilbar in Subdomänen (inhaltliche Teile) und Partitionen (verschiedene Sichten) (z.B. Trennung Fachsicht und

Techniksicht, Persistenz als Subdomäne) Definition Metamodell ([MDSD*05], S.67): • Formalisierung struktureller Eigenschaften der Domäne • Syntax durch Metametamodell spezifiziert, z.B. Ecore bei EMF

abstrakte Syntax: Festlegung der Sprachstruktur konkrete Syntax: von einem Parser akzeptierte Eingaben der Sprache statische Semantik: Wohlgeformtheitskriterien der Domäne (Regeln, die

durch die Domäne vorgegeben werden, die aber in der Syntax des Metamodells nicht eingehalten werden)

Definition Domänenspezifische Sprache (DSL) ([MDSD*05], S.68): • verwendete Syntax und statische Semantik des Metamodells • dynamische Semantik: Bedeutung der Konstrukte aus dem Metamodell (entweder selbsterklärend oder gut dokumentiert) • Ausdrucksmächtigkeit und Abstraktionsniveau sind dem Problem entsprechend gewählt



Modellierung und DSLs (2)

Begriffbildung - Modellierung und DSLs ([MDSD*05], S.66)



Plattform und Transformation (1)

Definition Plattform ([MDSD*05], S. 70): • Umsetzung der Domäne • besteht aus Bausteinen (Middleware, Bibliotheken, Framework, Komponenten, Aspekten) • kaskadierbar (d.h. eine Plattform setzt auf andere Plattformen auf) Transformationen ([MDSD*05], S.71): • basieren auf Quellmetamodell (Transformationsvorschiften operieren auf ihm) • stellen Semantik der DSL dar Definition Plattform-Idome ([MDSD*05], S.72): • Codegenerierung basierend auf Patterns (z.B. Business Delegate) macht unabhängig von konkreten Programmiermodellen (z.B.

EJBs)



Plattform und Transformation (2)

Begriffsbildung - Transformationen ([MDSD*05], S-71)



Domänenarchitektur (1)

Definition Architektur ([MDSD*05], S. 129): • besitzt eine Struktur (Schichten, Module) und folgt Konzepten (Muster, Stil) • Aufgaben: Abbildung der Fachlichkeit

Komplexitätsbewältigung (dokumentativ) Erleichterung der Erweiterbarkeit und Wartbarkeit

Definition Domänenarchitektur ([MDSD*05], S. 73): • Summe aus Domänenmetamodell, Plattform und Transformationen • bildet ab, welche Konzepte formal unterstützt werden sollen und wie diese auf eine Plattform umzusetzen sind (die Plattform ist

die Laufzeitumgebung für die Domänenarchitektur)

Software-Systemfamilie ([MDSD*05], S.73): • Menge aller Produkte, die sich mit bestimmter Domänenarchitektur erstellen lassen Produktlinie ([MDSD*05], S. 74): • ist die Menge fachlich aufeinander abgestimmter Einzelprodukte • alternativ oder ergänzend einsetzbar • Produkte sind technisch nicht notwendigerweise abhängig voneinander • kann einer Software-Systemfamilie zu Grunde liegen



Domänenarchitektur (2)

Begriffbildung - Domäne, Produktlinie, Software-Systemfamilie ([MDSD*05], S-73)



Erstellen der Domänenarchitektur

Erstellen einer Domänenarchitektur ([MDSD*05], S. 204)



openArchitectureWare

• Allgemeine Beschreibung und Aufgabe • Funktionsweise des oAW-Generators • Beschreibung der Funktionen • Bestandteile • Abbildung der MDSD in openArchitectureWare • Bestandteile der openArchitectureWare-Distribution • Konfiguration von openArchitectureWare



Allgemeine Beschreibung und Aufgabe

• laut [Fact06] ist openArchitectureWare eine Sammlung von Werkzeugen, die die modellgetriebene Entwicklung unterstützen sollen

• mit openArchitectureWare sollen MDA/MDSD-Werkzeuge erstellt werden können • baut auf einem modularen Generator-Framework auf und ist mit Java implementiert • OpenSource und Teil des Eclipse GMT (Generative Model Transformer) Projektes • Werkzeuge wie Editoren und Modellnavigatoren sind Eclipse-Plugins • mit openArchitectureWare soll der Prozess der domänenspezifischen Modellierung abgedeckt werden: ein durch eine DSL

beschriebener Problemraum soll durch auf Konfigurationswissen basierende Transformationen in einen durch eine konkrete Zielplattform realisierten Lösungsraum überführt werden

DSL Transformationen (Ziel-)Plattform

Problemraum Konfigurationswissen Lösungraum

wird beschrieben durch wird beschrieben durch wird beschrieben durch

Quelle: eigene Darstellung



Funktionsweise des oAW-Generators

Funktionsweise des openArchitectureGenerators ([MDSD*05], S. 111)

• ein vorgegebenes Modell wird vom Workflow eingelesen und geparst • der Metamodellinstantiator verwebt die Metamodelle, auf denen das Modell basiert und die unterschiedlicher Syntax haben

können, und das eingeparste Eingabemodell zu einer einzigen Metamodellinstanz (Metamodellinstanz = Modell), die noch Referenzen auf die Ausgangsmetamodelle hält

• in den Templates ist definiert, wie aus den Elementen und Strukturen der Metamodelle Elemente und Strukturen des Zielmodells generiert werden sollen

• die Templates werden mittels des Code Generators auf die geschaffene Metamodellinstanz angewendet, um nun ein Zielmodell (z.B. bestimmter Programmcode) zu erzeugen



Beschreibung der Funktionen (1)

• die Workflow-Engine steuert den Prozessablauf, so wie er in der XML-Workflowdefinitionsdatei beschrieben wurde • mittels verschiedenen Modell-Instanziierern können momentan EMF, Ausgabeformate diverse UML-Werkzeuge (nebst deren

verschiedenen Versionen), Eclipse UML2, XML, Visio, textuelle Modelle sowie pure::variants Konfiguartinsmodelle eingelesen und verwoben werden

• XPand2 ist eine eigens entwickelte Templatesprache, die Konzepte wie Aspekte und Polymorphismus unterstüzt, um auf den Quellmodellen navigierend komplexe Code-Generatoren erzeugen zu können

• Metamodelle können entweder mittels Eclipse Modeling Framework (EMF) oder mit dem oAW-eigenen Metamodellgenerator erzeugt werden, dieser erstellt Java-Klassen auf Grundlage von UML-Metamodellen (die wichtigesten UML-Metamodellklassen für die Verwendung in UML-Profiles sind vorhanden)

• für die Formulierung und Überprüfung von Bedingungen (Constraints) stehen mehrere Möglichkeiten zur Verfügung (Java-API, Check-Language oder KentOCL), Bedingungen können dabei modellübergreifend gesetzt werden

• Metamodellerweiterungen (zusätzliche Metamodelleigenschaften außerhalb des Metamodell, nur in den Templates verfügbar) lassen sich durch eine an OCL angelehnte oAW-eigene Sprache oder entsprechende Einschübe in Java spezifizieren

Quelle: [Fact06]



Beschreibung der Funktionen (2)

• Modell-zu-Modell-Umformungen werden über die mitgelieferte Sprache xTend bewerkstelligt; charakteristisch an dieser Sprache ist, dass eine Funktion nur einmal evaluiert wird, statt sie bei jedem neuen Aufruf an anderer Stelle nochmals zu prüfen; alternativ zu dieser Sprache werden auch Drittanbieterprodukte wie z.B. ATL (Atlas Transformation Language) unterstützt

• Validierungsregeln, die sich für die Integration von generierten und nicht-generierten Code aufstellen lassen, werden in openArchitectureWare mit dem Recipe-Framework definiert und werden bei der Codegenerierung angewendet

• über Eclipse-Plugins werden für Sprachen wie xPand oder xTend Editoren bereitgestellt, die Syntax-Erkennung, Codevervollständigung, Fehleranzeige unterstützen

• Checks des Recipe-Frameworks werden bei Änderungen im Code sofort validiert und mögliche Regelverstöße angezeigt

• die Erzeugung eines Editors für die selbst definierte DSL wird bisher mit GMF (Graphical Modeling Framework) für grafische Editoren und dem oAW-eigenen xText für textuelle Editoren unterstützt



Abbildung der MDSD in openArchitectureWare



Bestandteile der openArchitectureWare-Distribution

• oAW-Core-Paket Workflow Engine Integration mit EMF XPand2 Engine Wombat Engine (deren Funktion wird in oAW 4.1 von xTend übernommen)

• oAW-Core-Plugins-Paket Integration in die Eclipse IDE, insbesondere durch Editoren für XPand2, xTend und Check Editor sowie Workflow Launcher

• oAW-Adaptoren-Paket Adaptoren zu Drittanbieterwerkzeugen, z.B. KentOCL, ATL, UML

• oAW-Recipe-Paket (mit Integration in die Eclipse IDE) • oAW-Classic-Paket (nur für die oAW-Classic Unterstützung benötigt)



Konfigurierung von openArchitectureWare

• Installation von Eclipse 3.1.x mit EMF, GEF, JEM und bei Bedarf mit Omondo EclipseUML2 • eine ausführliche Installationsanleitung findet sich in [Völt06a] • Herunterladen der oAW-Pakete von der Projektseite • Setzen der oAW-Bibliotheken in den Eclipse Klassenpfad

OAW_CORE, OAW_LIB, OAW_RECIPE_CORE • Auswahl des anzuwendenden Metametamodells unter Windows Preferences openArchitectureWare in Eclipse

JavaBeans-Metamodell oAW-Classic-Metamodell EMF-Metamodelle UML2 Profiles

• Erstellen des Metamodells mit einem durch die mitgelieferten Adaptoren unterstützten UML-Werkzeuges (versionsabhängig) oder gleich mit dem integrierten EMF-Editor



Praktisches Beispiel

• Beispiel-Domäne: Elektronisches Meldewesen bei der Bundesbank • Analyse der Domäne Meldewesen • Festlegung der Zielplattform • Definition des Metamodells • Generierung des Modell-Editors • Anlegen eines neuen Modells • Referenzieren des Modells im Workflow • Templates definieren • Extensions definieren • Checks definieren • Recipe definieren • Beispiel-Workflow



Beispiel-Domäne: Elektronisches Meldewesen bei der Bundesbank (1)

Domänenbeschreibung: Geschäftsbanken sind gesetzlich verpflichtet in regelmäßigen Abständen Statistiken und bankenaufsichtliche Meldungen an die Deutsche Bundesbank weiterzuleiten. Die Meldungen gehen in elektronischer Form ein und deren Annahme bzw. Ablehnung soll automatisiert werden. Zu erfüllende Bedingungen für die Annahme einer Meldung • Eingang der Meldung zwischen 7.00 und 20.00 Uhr von Montag bis Freitag • benötigte Anträge wurden dem zuständigen Sachbearbeiter zugesandt • Einhaltung des geforderte Meldung-Datenformats

vorgegeben sind folgende Daten • Meldungstypen • Zuordnung der Sachbearbeiter zu jedem Meldungstyp • Datenformat mit Bedeutungen des jeweiligen Feldes • Fehlercodes mit Fehlerbeschreibungen Prozesse und Funktionen • Prüfung der Korrektheit des Meldungseingangs • Analyse der Meldung • bei bankenaufsichtlichen Meldung wird Eingang bestätigt • Fehlermeldungen werden an den Meldungseinreicher weitergeleitet



Beispiel-Domäne: Elektronisches Meldewesen bei der Bundesbank (2)

Ziele: • Generieren der WebServices, die die einzelnen Funktionen realisieren • Generieren der Datentypen in XML-Schema (z.B. Fehlercodes) • Generieren eines BPEL-Prozesses für die Meldungseingangsbearbeitung

Variabilitäten • neue Bedingungen für die Annahme von Meldungen • alte Anforderungen ändern sich oder werden entfernt • geforderter Datentyp der Meldung ändert sich • Sachbearbeiter-Zuständigkeiten ändern sich • Meldungstypen werden umstrukturiert • Fehlercodes bzw. deren Zuordnung ändert sich • Prozessbeschreibungssprache ändert sich (z.B. neue BPEL-Version)

Vorgehen: • Modellieren der Domänenelementen in den jeweils geeigneten DSLs • Definition der Transformationen aus Domänenmodell in XSDs, WSDLs und BPEL • Ableiten möglicher Generierungs-Templates • Generierung eines Modellierungstools • Umsetzung in der Eclipse IDE



Analyse der Domäne Meldewesen (1)

• Rollen Geschäftsbank (als Meldungseinreicher) Bundesbank (als Meldungsbearbeiter)

• Datentypen Meldung (Vorsatz, Datensatz, Nachsatz) Fehlermeldung (Fehlercode) Zeitpunkt (Wochentag, Uhrzeit)

• Funktionen Meldung prüfen (Zeitraum, vollständige Anträge) Meldung analysieren (Typ) Bestätigungs- oder Fehlermeldung schicken



Analyse der Domäne Meldewesen (2)

Meldungeingang

Zeitraumpüfung

Ist in Zeit? Fehlermeldung F01 senden nein

Antragspüfung vollständig? ja

Fehlermeldung F02 senden

Meldungstyp auslesen

nein

ja

Ist BA?

Bestätigung senden

{Zeitpunkt: Ende des Quartals} ja

nein



Festlegung der Zielplattform

• Umsetzen der Domäne als BPEL-Prozess Prozess wird in bpel-Datei abgebildet Funktionen in WSDL als Operationen in PortTypes umgesetzt Datentypen werden mittels XML-Schema definiert

• Implementierung Datenbankzugriff mit Hibernate oder mit EJB Entity Beans realisierbar Geschäftslogik mittels EJB Session Beans oder Springframework umsetzbar WebServices als Definition des Zugriffs auf die Geschäftslogik Erstellen von SOAP-Nachrichten Erstellung eines Web-Formulars



Definition des Metamodells

• mittels Ecore-Editor lässt sich das Metamodell erstellen und mit Hilfe EMF Class Diagram Editor darstellen



Generierung des Modell-Editor

• aus dem Ecore-Modell muss EMF-Modell generiert werden

• über das EMF-Modell können nun Plugins für das Erstellen und Editieren eines Modells generiert werden, die der Syntax des eben in Ecore definierten Metamodells gehorcht

• es muss nun eine Eclipse-Umgebung gestartet werden, die diese Plugins lädt, um Editierfunktion als auch Editor benutzen zu können



Anlegen eines neuen Modells

• man kann nun ein neues Projekt anlegen und diesem die oAW Nature verleihen sowie ihm die benötigten Bibliotheken hinzufügen und die Referenz auf das Metamodell-projekt setzen

• es lässt sich jetzt ein EMF-Modell anlegen, dass unserem Metamodell folgt

• durch einen Editor wird man bei der Erstellung eines Modells unterstützt



Modell im Workflow referenzieren

Datei workflow.oaw <workflow>

<property file=„worklfow.properties“ /> <component id=„xmiParser“ class=„org.openarchitectureware.emf.XmiReader“> <modelFile value=„${modelFile}“ /> <metaModelPackage value=„data.DataPackage“ /> <outputSlot value=„model“ /> <firstElementOnly value=„true“ /> </component> ... </workflow>

• Die Modelldatei wird über den für EMF verfügbaren XMIReader eingelesen, das zugehörige Metamodellpaket referenziert und das Modell über eine Ausgabeschnittstelle den im Workflow existierenden Aufgaben (z.B. Templatesaufrufe, Checks) zur Verfügung gestellt.

• Näheres über die Anwendung von EMF und openArchitectureWare 4 findet sich in [Völt06b]



Templates definieren

• mit Hilfe der Templates werden auf Grundlage der Elemente des Modells spezifische Ausgaben erzeugt, eine Sprachreferenz findet sich in [Eff*06] • Templates können Aufgaben an andere Templates delegieren, so dass eine übersichtliche Baumstruktur entwickelt werden kann • im Workflow muss nur die oberste Templatedatei referenziert werden

Datei template.xpt <<DEFINE Root FOR meldewesen::Fehlercodes>>

<<EXPAND Fehlercode FOREACH fehlercode>> <<ENDDEFINE>>

<<DEFINE Fehlercode FOR meldewesen::Fehler>> <<FILE name+“.xsd“>> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://orvia.de/datentypen"

xmlns:tns="http://orvia.de/datentypen">

<xsd:complexType name=”<<name>>“>

<<FOREACH attribute AS a>>

<xsd:attribute name=“<<a.name>>"

type=“xsd:string”/>

<<ENDFOREACH>>

</xsd:complexType>

</xsd:schema>

<<ENDFILE>>

<<ENDDEFINE>>



Extensions definieren

• Extensions erweitern das Metamodell ohne selbiges verändern zu müssen, dies ist sinnvoll, wenn die Erweiterungen allein für eine spezielle Ausgabe benötigt werden und direkt im Metamodell definiert dieses nur „verschmutzen“ würden

• Extensions können an beliebigen Stellen definiert werden, in der Regel werden sie in den Templates referenziert • typische Extensions sind z.B. Vorgaben für umzusetzende Namenskonventionen • eine Sprachreferenz findet sich in [Eff06a]

Dateien extension.xpt und extension.ext (außerhalb des WSDL-Beispiels)

«FOREACH attribute AS a» private «a.type» «a.name»; public void «a.setterName()»( «a.type» value ) { this.«a.name» = value; } public «a.type» «a.getterName()»() { return this.«a.name»; } «ENDFOREACH»

import data; String setterName(Attribute ele) : 'set'+ele.name.toFirstUpper(); String getterName(Attribute ele) : 'get'+ele.name.toFirstUpper();



Checks definieren

• mit Checks werden Bedingungen definiert, die im Allgemeinen nicht direkt im Metamodell umgesetzt werden konnten, weil sie semantische Einschränkungen sind

• Checks lassen sich auf bestimmte Namensräume oder Elementgruppen definieren • es wird logischer Ausdruck überprüft, z.B. ob ein Name eines Elements eine bestimmte Länge hat, und eine Fehler- oder

Warnmeldung definiert, die bei Ausführung des Workflows ausgegeben wird, falls der logische Ausdruck verletzt wird • Check-Datei werden direkt im Workflow referenziert • eine Sprachreferenz findet sich in [Eff06b]

Datei check.chk import meldewesen; context Fehlercode ERROR „class darf nur zwei Zeichen lang sein“ : class.length < 3;



Recipe definieren

• mit dem Recipe-Framework lassen sich Checks definieren, die überprüfen, ob manuell geschriebener Code bestimmte Anforderungen erfüllt, um mit dem generierten Code zusammenarbeiten zu dürfen

• so wird typischerweise geprüft, ob z.B. eine manuelle Klasse von generierter Klasse erbt oder ob sie auch abstrakte Methoden überschreibt

• Recipe-Dateien werden direkt im Workflow referenziert • eine Sprachreferenz findet sich in [Völt06c]

Datei recipe.recipes (überprüft ob eine Java-Klasse existiert) public class RecipeCreator extends RecipeCreationComponent { protected Collection createRecipes(Object modelSlotContent, String appProject, String srcPath) { List checks = new ArrayList(); Collection entities = EmfUtil2.findAllByType(((DataModel)modelSlotContent).eAllContents(), Entity.class ); for (Iterator iter = entities.iterator(); iter.hasNext();) { Entity e = (Entity) iter.next(); ElementCompositeCheck ecc = new ElementCompositeCheck(e, "manual implementation of entity"); JavaClassExistenceCheck javaClassExistenceCheck = new JavaClassExistenceCheck( "you have to provide an implementation class.", appProject, srcPath, EntityHelper.implementationClassName(e)); ecc.addChild( javaClassExistenceCheck ); checks.add( ecc ); return checks; } } }



Beispiel-Workflow

<workflow> ... <component id=„generator“ class=„org.openarchitectureware.xpand2.Generator“> <metaModel id=„mm“ class=„org.openarchitectureware.type.emf.EmfMetaModel“> <metaModelPackage value=„meldewesen“ /> </metamodel> <expand value=„templates::Root::Root FOR model“ /> <genPath value=„${src.gen}“ /> <srcPath value=„${src.gen}“ /> <beautifier class=„org.openarchitectureware.put.XMLBeautfier“ /> </component> <component class=„org.openarchitectureware.check.CheckComponent“> <metaModel id=„mm“ class=„org.openarchitectureware.type.emf.EmfMetaModel“> <metaModelPackage value=„meldewesen“ /> </metamodel> <checkFile value=„fehlerCodeCheck“ /> <expression value=„model.eAllContents“ /> <component> <component id="recipe„ class="datamodel.generator.RecipeCreator"> <appProject value="oaw4.demo.emf.datamodel.generator"/> <srcPath value="man-src"/> <modelSlot value="model"/> <recipeFile value="recipes.recipes"/> </component> </workflow>



Vergleich mit Vorgängerversionen

• Verbesserungen gegenüber openArchitectureWare 3 • openArchitectureWare 3 Generator Framework



Verbesserungen gegenüber oAW 3

In [CGN06] nennt Markus Völter folgende Verbesserungen • Unterstützung von EMF zusätzlich zu MOF, Java-Beans und des oAW-eigenen Metamodells (oAW-Classic) • mit xPand2 nun unter anderem auch nun Definition von aspektorientierte Templates möglich • Modellvalidierung und Definition von Bedingungen kann nun mit Sprache Check erfolgen, zuvor musste man von jedem

Modellelement die vordefinierte Check-Methode überschreiben • Sprache xTend zum Erweitern von Metamodellen ohne selbige ändern zu müssen, sie löst die bisherigen Invokers ab; in Version

4.1. übernimmt xTend auch die Aufgabe der Modell-zu-Modell-Transformationen, die in Version 4 zwischenzeitlich von der Sprache Wombat umgesetzt wurden

• bessere Steuerbarkeit durch neu eingeführte Workflow-Engine, die ein an ANT-Skripte angelehntes Workflow-Dokument abarbeitet, sie löst die zuvor verwendete AntUI ab

• mit dem Recipe-Framework ist nun auch die kontrollierte Verknüpfung von manuellen und generierten Code möglich • bessere Modularisierung und Strukturierung, bessere Integration in Eclipse und ausführliche Beispiele und Dokumentation

geliefert • weitere Änderungen werden in [Kad06] beschrieben



openArchitectureWare 3 Generator Framework

Funktionsweise des openArchitectureWare 3 Generator Frameworks ([MDSD*05], S. 57)



Codegenerierungsverfahren

• Templates und Filters • Template und Metamodell • Frameprozessor • API-basierte Generatoren • Inline-Generierung • Code-Attribute • Code-Weaving



Codegenerierungsverfahren (1)

Templates und Filter ([MDSD*05], S. 176): • direkte Codegenerierung (z.B. XML in Java-Code mittels XSLT) • in Zielmodell-Schablone werden Elemente des Quellmodells referenziert, dazu wird meist iterativ über die Modellstruktur

navigiert • Problem der hohen Komplexität der Schablonen bei großen Modellen Template und Metamodell ([MDSD*05], S.178): • mehrstufiger Generator (z.B. XML Metamodell Transformation) • wird unabhängiger von konkreter Syntax des Metamodells (XMI-Versionen) • komplexe Modellverifikationslogik kann ins Metamodell verlagert werden • wird in openArchitectureWare verwendet

offenes Compilerframework, da Compiler mit abstrakter Syntax aus dem Metamodell und den Transformationen parametrisiert wird

objektorientierter Compiler, da Metamodellkonstrukte (=Synatxkonstrukte) sich selbst übersetzen Frameprozessor ([MDSD*05], S.179):

Frame spezifiert zu generierenden Code (entspricht Konzept der Klasse) Frame-Attribute, so genannte Slots, werden in den Frameinstanzen an konkrete Werte, Strings oder weitere Frames,

gebunden zur Laufzeit wird also Baumstruktur von Frameinstanzen gebildet, die die Struktur des zu generierenden Programms

darstellen



Codegenerierungsverfahren (2)

API-basierte Generatoren ([MDSD*05], S.181): • Bereitstellung einer API, mit der Elemente des Zielmodells erzeugt werden • Generator ist an abstrakte Syntax des Metamodells gebunden • Beispiel: Methode main in Java hat immer die gleiche Signatur, deren Definition kann daher auslagert werden und stattdessen

gerufen lassen werden Inline-Generierung (Template-Metaprogrammierung) ([MDSD*05], S.183): • Modell enthält mehrere Variantenspezifikationen, die gekennzeichnet sind • in der Konfiguration wird bestimmt, welche dieser Variantionen bei der Compilierung aufgleöst werden • Compiler wird mit bestimmter Konfiguration gestartet und ein bestimmtes Zielmodell kompiliert Code-Attribute (z.B. XDoclet) ([MDSD*05], S.185): • mit Kommentaren im Modell werden Eigenschaften und Einstellungen festgehalten • Kommentare im Modell werden vom Compiler ausgelesen und abhängig an welcher Stelle die Kommentare im Modell gefunden

worden, Zielmodelle erstellt Code-Weaving (z.B. AspectJ) ([MDSD*05], S.186): • aspektorientierte Programmierung • Zusammenfügen vollständiger unabhängiger Codebestandteile, z.B. Logger • im Programmcode werden Markierungen gesetzt, wo der Compiler den Aspektcode einweben soll



Fazit

• openArchitectureWare 4 ist mehr als nur ein weiterer Templateprozessor • mit oAW4 lässt sich das modellgetriebene Entwicklungsprinzip vollständig abbilden • durch den generischen Ansatz bekommt der Entwickler größere Freiheiten als mit herkömmlichen MDA-Werkzeugen • es werden keine Einschränkung hinsichtlich verarbeitbarer Modelle gemacht, so dass es dem Domänenexperten frei steht, wie er

seine domänenspezifische Sprache ausgestaltet • mit oAW4 wird dem Erstellen und Verarbeiten von Templates die Überprüfung von zusätzlichen Bedingungen unterstützt, die

sicher stellen, dass das verwendete Modelle und der generierte Code tatsächlich auch den fachlichen Anforderungen genügt • wegen des flexiblen Ansatzes hat man bisher verzichtet, vordefinierte Templatesammlungen für bestimmte Domänen und

Techniken mitzuliefern und es somit dem Anwender auferlegt, alle Templates selber schreiben zu müssen • es ist allerdings davon auszugehen, dass in zukünftigen Versionen solche Sammlungen integriert sein werden, da es viele

Elemente gibt, die immer wiederkehrend sind und daher vernünftigerweise schon als Referenz zur Verfügung gestellt werden können, wie das bei Werkzeugen wie androMDA bereits der Fall ist, ohne dabei den generischen Ansatz verlieren zu müssen



Literatur

• [CGN06] Code Generation Interview mit Markus Völter, http://www.voelter.de/data/articles/cgn.pdf, 2006 • [Eff06a] Efftingen, Sven: Extend Language Reference, http://www.eclipse.org/gmt/oaw/doc/r25_extendReference.pdf, 2006 • [Eff06b] Efftingen, Sven: Check – Validation Language, http://www.eclipse.org/gmt/oaw/doc/r30_checkReference.pdf, 2006 • [Eff*06] Efftingen, Sven, Kadura, Clemens: XPand Language Reference,

http://www.eclipse.org/gmt/oaw/doc/r20_xPandReference.pdf, 2006 • [Fact06] oAW Fact Sheet, http://www.eclipse.org/gmt/oaw/oAWFactSheet.pdf, 2006 • [Kad06] Kadura, Clemens: oAW 4 Migration, http://www.eclipse.org/gmt/oaw/doc/25_migrationAndOAWClassic.pdf, 2006 • [MDSD*05] Stahl, Thomas; Völter, Markus: Modellgetriebene Softwareentwicklung - Techniken, Engineering, Management,

dpunkt.verlag, 2005 • [Völt05] Völter, Markus: Modellgetriebene Softwareentwicklung, http://www.voelter.de/data/articles/DBS-MDSD.pdf, 2005 • [Völt06a] Völter, Markus: oAW 4 Installation, http://www.eclipse.org/gmt/oaw/doc/10_installation.pdf, 2006 • [Völt06b] Völter, Markus: oAW 4 EMF Example, http://www.eclipse.org/gmt/oaw/doc/30_emfExample.pdf, 2006 • [Völt06c] Völter, Markus: Recipe Framework Reference, http://www.eclipse.org/gmt/oaw/doc/r40_recipeReference.pdf, 2006

Technology

Using openArchitectureWare 4.0 in domain "registration"