Using openArchitectureWare 4.0 in domain "registration"

Institut für Informatik
Betriebliche Informationssysteme

openArchitectureWare 4.0
Endpräsentation
Jörg Reichert

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.

1

Gliederung
1.
2.
3.
4.
5.
6.


Einführung
Begriffe
Vorgehensprinzipien
openArchitectureWare
Praxis-Beispiel mit openArchitectureWare
Fazit

© Universität Leipzig 2006

2

Einführung
•
•
•
•


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


3

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)


4

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


5

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


6

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


7

Begriffe
•
•
•


Modellierung und DSL
Plattform und Transformation
Domänenarchitektur


8

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
nicht eingehalten werden)

Syntax des Metamodells

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


9

Modellierung und DSLs (2)


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


10

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)


11

Plattform und Transformation (2)


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


12

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


13

Domänenarchitektur (2)


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


14

Erstellen der Domänenarchitektur


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

15

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


16

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

Problemraum
wird beschrieben durch

DSL

Konfigurationswissen

Transformationen

Lösungraum

(Ziel-)Plattform
Quelle: eigene Darstellung


17

Funktionsweise des oAW-Generators
•
•

•
•


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

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

18

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]

19

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


20

Abbildung der MDSD in openArchitectureWare



21

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)


22

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


23

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


24

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

25

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


26

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


27

Analyse der Domäne Meldewesen (2)


Meldungeingang

Fehlermeldung F02 senden

Zeitraumpüfung

nein
Fehlermeldung F01 senden

nein

Ist in Zeit?

ja

Antragspüfung

vollständig?
ja

nein

{Zeitpunkt: Ende des Quartals}

Ist BA?

Meldungstyp auslesen

ja

Bestätigung senden


28

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


29

Definition des Metamodells

•


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


30

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

31

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 EMFModell anlegen, dass
unserem Metamodell folgt
durch einen Editor wird
man bei der Erstellung eines
Modells unterstützt

32

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]


33

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>>


34

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;
}

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

public «a.type» «a.getterName()»() {
return this.«a.name»;
}
«ENDFOREACH»


35

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;


36

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;
}
}
}

37

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>

38

Vergleich mit Vorgängerversionen
•
•


Verbesserungen gegenüber openArchitectureWare 3
openArchitectureWare 3 Generator Framework


39

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


40

openArchitectureWare 3 Generator Framework


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


41

Codegenerierungsverfahren
•
•
•
•
•
•
•


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


42

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


43

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


44

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


45

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


46

Using openArchitectureWare 4.0 in domain "registration"

Recommandé

Recommandé

Contenu connexe

Similaire à Using openArchitectureWare 4.0 in domain "registration"

Similaire à Using openArchitectureWare 4.0 in domain "registration" (20)

Plus de joergreichert

Plus de joergreichert (17)

Using openArchitectureWare 4.0 in domain "registration"