using openarchitectureware 4.0 in domain "registration"
DESCRIPTION
Some retro: This presentation dated 2006 shows how to do model driven software development with openArchitectureWare 4.0 in the example domain "registration". Although openArchitectureWare is now superseded by Xtext, Xtend2 and Xbase it is always good to remember the principles of model driven software development.TRANSCRIPT
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 2
Gliederung
1. Einführung 2. Begriffe 3. Vorgehensprinzipien 4. openArchitectureWare 5. Praxis-Beispiel mit openArchitectureWare 6. Fazit
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 3
Einführung
• Modellgetriebene Softwareentwicklung • Motivation und Ziele • Entstehungsgeschichte • Abgrenzung des MDSD- vom MDA-Ansatz
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 4
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)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 5
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 6
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 7
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 8
Begriffe
• Modellierung und DSL • Plattform und Transformation • Domänenarchitektur
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 9
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 10
Modellierung und DSLs (2)
Begriffbildung - Modellierung und DSLs ([MDSD*05], S.66)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 11
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)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 12
Plattform und Transformation (2)
Begriffsbildung - Transformationen ([MDSD*05], S-71)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 13
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 14
Domänenarchitektur (2)
Begriffbildung - Domäne, Produktlinie, Software-Systemfamilie ([MDSD*05], S-73)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 15
Erstellen der Domänenarchitektur
Erstellen einer Domänenarchitektur ([MDSD*05], S. 204)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 16
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 17
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 18
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 19
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]
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 20
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 21
Abbildung der MDSD in openArchitectureWare
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 22
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)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 23
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 24
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 25
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 26
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 27
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 28
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 29
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 30
Definition des Metamodells
• mittels Ecore-Editor lässt sich das Metamodell erstellen und mit Hilfe EMF Class Diagram Editor darstellen
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 31
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 32
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 33
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]
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 34
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>>
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 35
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();
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 36
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;
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 37
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; } } }
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 38
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>
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 39
Vergleich mit Vorgängerversionen
• Verbesserungen gegenüber openArchitectureWare 3 • openArchitectureWare 3 Generator Framework
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 40
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 41
openArchitectureWare 3 Generator Framework
Funktionsweise des openArchitectureWare 3 Generator Frameworks ([MDSD*05], S. 57)
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 42
Codegenerierungsverfahren
• Templates und Filters • Template und Metamodell • Frameprozessor • API-basierte Generatoren • Inline-Generierung • Code-Attribute • Code-Weaving
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 43
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 44
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 45
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
Institut für Informatik Betriebliche Informationssysteme
© Universität Leipzig 2006 46
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