SlideShare ist ein Scribd-Unternehmen logo
1 von 46
Downloaden Sie, um offline zu lesen
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.

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

2
Einführung
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

3
Modellgetriebene Softwareentwicklung

Institut für Informatik
Betriebliche Informationssysteme

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)

© Universität Leipzig 2006

4
Motivation und Ziele

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

5
Entstehungsgeschichte

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

6
Abgrenzung des MDSD- vom MDA-Ansatz
•

•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

7
Begriffe
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

Modellierung und DSL
Plattform und Transformation
Domänenarchitektur

© Universität Leipzig 2006

8
Modellierung und DSL (1)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

9
Modellierung und DSLs (2)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

10
Plattform und Transformation (1)

Institut für Informatik
Betriebliche Informationssysteme

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)

© Universität Leipzig 2006

11
Plattform und Transformation (2)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

12
Domänenarchitektur (1)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

13
Domänenarchitektur (2)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

14
Erstellen der Domänenarchitektur

Institut für Informatik
Betriebliche Informationssysteme

Erstellen einer Domänenarchitektur ([MDSD*05], S. 204)
© Universität Leipzig 2006

15
openArchitectureWare
•
•
•
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

16
Allgemeine Beschreibung und Aufgabe
•
•
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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
wird beschrieben durch

Transformationen

Lösungraum
wird beschrieben durch

(Ziel-)Plattform
Quelle: eigene Darstellung

© Universität Leipzig 2006

17
Funktionsweise des oAW-Generators
•
•

•
•

Institut für Informatik
Betriebliche Informationssysteme

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)
© Universität Leipzig 2006

18
Beschreibung der Funktionen (1)
•
•

•
•

•
•

Institut für Informatik
Betriebliche Informationssysteme

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]
© Universität Leipzig 2006

19
Beschreibung der Funktionen (2)
•

•

•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

20
Abbildung der MDSD in openArchitectureWare

© Universität Leipzig 2006

Institut für Informatik
Betriebliche Informationssysteme

21
Bestandteile der openArchitectureWare-Distribution
•

•

•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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)

© Universität Leipzig 2006

22
Konfigurierung von openArchitectureWare
•
•
•
•
•

•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

23
Praktisches Beispiel
•
•
•
•
•
•
•
•
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

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

Institut für Informatik
Betriebliche Informationssysteme

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
© Universität Leipzig 2006

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

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

26
Analyse der Domäne Meldewesen (1)
•

•

•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

27
Analyse der Domäne Meldewesen (2)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

28
Festlegung der Zielplattform
•

•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

29
Definition des Metamodells

•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

30
Generierung des Modell-Editor

Institut für Informatik
Betriebliche Informationssysteme

•
•

•

© Universität Leipzig 2006

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

Institut für Informatik
Betriebliche Informationssysteme

•

•
•

© Universität Leipzig 2006

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

Institut für Informatik
Betriebliche Informationssysteme

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]

© Universität Leipzig 2006

33
Templates definieren
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

34
Extensions definieren
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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»

© Universität Leipzig 2006

35
Checks definieren
•
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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;

© Universität Leipzig 2006

36
Recipe definieren
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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;
}
}
}
© Universität Leipzig 2006

37
Beispiel-Workflow

Institut für Informatik
Betriebliche Informationssysteme

<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>
© Universität Leipzig 2006

38
Vergleich mit Vorgängerversionen
•
•

Institut für Informatik
Betriebliche Informationssysteme

Verbesserungen gegenüber openArchitectureWare 3
openArchitectureWare 3 Generator Framework

© Universität Leipzig 2006

39
Verbesserungen gegenüber oAW 3

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

40
openArchitectureWare 3 Generator Framework

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

41
Codegenerierungsverfahren
•
•
•
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

42
Codegenerierungsverfahren (1)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

43
Codegenerierungsverfahren (2)

Institut für Informatik
Betriebliche Informationssysteme

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

© Universität Leipzig 2006

44
Fazit

Institut für Informatik
Betriebliche Informationssysteme

•
•
•
•
•
•
•

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

© Universität Leipzig 2006

45
Literatur
•
•
•
•

•
•
•
•
•
•
•

Institut für Informatik
Betriebliche Informationssysteme

[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

© Universität Leipzig 2006

46

Weitere ähnliche Inhalte

Ähnlich wie Using openArchitectureWare 4.0 in domain "registration"

Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Andreas Schreiber
 
Java für eingebettete Systeme
Java für eingebettete SystemeJava für eingebettete Systeme
Java für eingebettete Systeme
rdmeyer
 

Ähnlich wie Using openArchitectureWare 4.0 in domain "registration" (20)

MDSD Herausforderung: Entwicklungsmethodik und technisches Umfeld
MDSD Herausforderung: Entwicklungsmethodik und technisches UmfeldMDSD Herausforderung: Entwicklungsmethodik und technisches Umfeld
MDSD Herausforderung: Entwicklungsmethodik und technisches Umfeld
 
Java User Group Düsseldorf - Vortrag der iks am 13. März 2008
Java User Group Düsseldorf - Vortrag der iks am 13. März 2008Java User Group Düsseldorf - Vortrag der iks am 13. März 2008
Java User Group Düsseldorf - Vortrag der iks am 13. März 2008
 
.NET und jetzt!
.NET und jetzt!.NET und jetzt!
.NET und jetzt!
 
AndroMDA - Einführung in eine Open Source Model Driven Architecture Lösung
AndroMDA - Einführung in eine Open Source Model Driven Architecture LösungAndroMDA - Einführung in eine Open Source Model Driven Architecture Lösung
AndroMDA - Einführung in eine Open Source Model Driven Architecture Lösung
 
Windows Azure Platform Overview
Windows Azure Platform   OverviewWindows Azure Platform   Overview
Windows Azure Platform Overview
 
2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
 
Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013
Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013
Leistungsvergleich Präsentationsoberflächen für digitale Sammlungen 2013
 
Anwendungsmodernisierung mit Oracle Application Express (APEX)
Anwendungsmodernisierung mit Oracle Application Express (APEX)Anwendungsmodernisierung mit Oracle Application Express (APEX)
Anwendungsmodernisierung mit Oracle Application Express (APEX)
 
DevDay 2017: Ralf Knobloch - "Einfacher leben mit DevOps bei der MMS !!" - De...
DevDay 2017: Ralf Knobloch - "Einfacher leben mit DevOps bei der MMS !!" - De...DevDay 2017: Ralf Knobloch - "Einfacher leben mit DevOps bei der MMS !!" - De...
DevDay 2017: Ralf Knobloch - "Einfacher leben mit DevOps bei der MMS !!" - De...
 
Migration einer Oracle Forms Anwendung - Rhenus Freight Network GmbH
Migration einer Oracle Forms Anwendung - Rhenus Freight Network GmbHMigration einer Oracle Forms Anwendung - Rhenus Freight Network GmbH
Migration einer Oracle Forms Anwendung - Rhenus Freight Network GmbH
 
Kevin Hofer
Kevin HoferKevin Hofer
Kevin Hofer
 
LightSwitch und SQL Azure: Datengetriebene Anwendungen in Rekordzeit erstellen
LightSwitch und SQL Azure: Datengetriebene Anwendungen in Rekordzeit erstellenLightSwitch und SQL Azure: Datengetriebene Anwendungen in Rekordzeit erstellen
LightSwitch und SQL Azure: Datengetriebene Anwendungen in Rekordzeit erstellen
 
imatics FormEngine
imatics FormEngineimatics FormEngine
imatics FormEngine
 
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
Apps for the Enterprise - Ein einheitliches Modulsystem für verteilte Unterne...
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
 
SokaHH: Testen von Rich-Web-UI (German)
SokaHH: Testen von Rich-Web-UI (German)SokaHH: Testen von Rich-Web-UI (German)
SokaHH: Testen von Rich-Web-UI (German)
 
Javamagazin 1.2016 jdk9_ea_b83_jigsaw
Javamagazin 1.2016 jdk9_ea_b83_jigsawJavamagazin 1.2016 jdk9_ea_b83_jigsaw
Javamagazin 1.2016 jdk9_ea_b83_jigsaw
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
 
Java für eingebettete Systeme
Java für eingebettete SystemeJava für eingebettete Systeme
Java für eingebettete Systeme
 

Mehr von joergreichert

Mehr von joergreichert (17)

OKLab Leipzig - 2023 Update
OKLab Leipzig - 2023 UpdateOKLab Leipzig - 2023 Update
OKLab Leipzig - 2023 Update
 
SDGs und wo sind die Daten?
SDGs und wo sind die Daten?SDGs und wo sind die Daten?
SDGs und wo sind die Daten?
 
Gieß a bit more the Bäume
Gieß a bit more the BäumeGieß a bit more the Bäume
Gieß a bit more the Bäume
 
OKLab Leipzig 2022
OKLab Leipzig 2022OKLab Leipzig 2022
OKLab Leipzig 2022
 
FAIRe Sensordaten
FAIRe SensordatenFAIRe Sensordaten
FAIRe Sensordaten
 
OKLab Leipzig 2021
OKLab Leipzig 2021OKLab Leipzig 2021
OKLab Leipzig 2021
 
Leipzig Giesst (Dezember 2020)
Leipzig Giesst (Dezember 2020)Leipzig Giesst (Dezember 2020)
Leipzig Giesst (Dezember 2020)
 
Road to mauAR
Road to mauARRoad to mauAR
Road to mauAR
 
OKLab Leipzig - Schwerpunkt Mobilität
OKLab Leipzig - Schwerpunkt MobilitätOKLab Leipzig - Schwerpunkt Mobilität
OKLab Leipzig - Schwerpunkt Mobilität
 
Die Stadt als Schule der Demokratie
Die Stadt als Schule der DemokratieDie Stadt als Schule der Demokratie
Die Stadt als Schule der Demokratie
 
OKLab Leipzig (2019 Update)
OKLab Leipzig (2019 Update)OKLab Leipzig (2019 Update)
OKLab Leipzig (2019 Update)
 
A Pattern Language - Patterns for Javascript
A Pattern Language - Patterns for JavascriptA Pattern Language - Patterns for Javascript
A Pattern Language - Patterns for Javascript
 
Unit testing mit Javascript
Unit testing mit JavascriptUnit testing mit Javascript
Unit testing mit Javascript
 
damals.in/leipzig
damals.in/leipzigdamals.in/leipzig
damals.in/leipzig
 
OkLab Leipzig (2018 Update)
OkLab Leipzig (2018 Update)OkLab Leipzig (2018 Update)
OkLab Leipzig (2018 Update)
 
Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT
Modell-getriebene Softwareentwicklung für Lego Mindstorms NXTModell-getriebene Softwareentwicklung für Lego Mindstorms NXT
Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT
 
Spray Democamp Dresden 2011-11-08
Spray Democamp Dresden 2011-11-08Spray Democamp Dresden 2011-11-08
Spray Democamp Dresden 2011-11-08
 

Using openArchitectureWare 4.0 in domain "registration"

  • 1. 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
  • 2. Gliederung 1. 2. 3. 4. 5. 6. Institut für Informatik Betriebliche Informationssysteme Einführung Begriffe Vorgehensprinzipien openArchitectureWare Praxis-Beispiel mit openArchitectureWare Fazit © Universität Leipzig 2006 2
  • 3. Einführung • • • • Institut für Informatik Betriebliche Informationssysteme Modellgetriebene Softwareentwicklung Motivation und Ziele Entstehungsgeschichte Abgrenzung des MDSD- vom MDA-Ansatz © Universität Leipzig 2006 3
  • 4. Modellgetriebene Softwareentwicklung Institut für Informatik Betriebliche Informationssysteme 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) © Universität Leipzig 2006 4
  • 5. Motivation und Ziele Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 5
  • 6. Entstehungsgeschichte Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 6
  • 7. Abgrenzung des MDSD- vom MDA-Ansatz • • • • Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 7
  • 8. Begriffe • • • Institut für Informatik Betriebliche Informationssysteme Modellierung und DSL Plattform und Transformation Domänenarchitektur © Universität Leipzig 2006 8
  • 9. Modellierung und DSL (1) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 9
  • 10. Modellierung und DSLs (2) Institut für Informatik Betriebliche Informationssysteme Begriffbildung - Modellierung und DSLs ([MDSD*05], S.66) © Universität Leipzig 2006 10
  • 11. Plattform und Transformation (1) Institut für Informatik Betriebliche Informationssysteme 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) © Universität Leipzig 2006 11
  • 12. Plattform und Transformation (2) Institut für Informatik Betriebliche Informationssysteme Begriffsbildung - Transformationen ([MDSD*05], S-71) © Universität Leipzig 2006 12
  • 13. Domänenarchitektur (1) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 13
  • 14. Domänenarchitektur (2) Institut für Informatik Betriebliche Informationssysteme Begriffbildung - Domäne, Produktlinie, Software-Systemfamilie ([MDSD*05], S-73) © Universität Leipzig 2006 14
  • 15. Erstellen der Domänenarchitektur Institut für Informatik Betriebliche Informationssysteme Erstellen einer Domänenarchitektur ([MDSD*05], S. 204) © Universität Leipzig 2006 15
  • 16. openArchitectureWare • • • • • • • Institut für Informatik Betriebliche Informationssysteme Allgemeine Beschreibung und Aufgabe Funktionsweise des oAW-Generators Beschreibung der Funktionen Bestandteile Abbildung der MDSD in openArchitectureWare Bestandteile der openArchitectureWare-Distribution Konfiguration von openArchitectureWare © Universität Leipzig 2006 16
  • 17. Allgemeine Beschreibung und Aufgabe • • • • • • Institut für Informatik Betriebliche Informationssysteme 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 wird beschrieben durch Transformationen Lösungraum wird beschrieben durch (Ziel-)Plattform Quelle: eigene Darstellung © Universität Leipzig 2006 17
  • 18. Funktionsweise des oAW-Generators • • • • Institut für Informatik Betriebliche Informationssysteme 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) © Universität Leipzig 2006 18
  • 19. Beschreibung der Funktionen (1) • • • • • • Institut für Informatik Betriebliche Informationssysteme 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] © Universität Leipzig 2006 19
  • 20. Beschreibung der Funktionen (2) • • • • • Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 20
  • 21. Abbildung der MDSD in openArchitectureWare © Universität Leipzig 2006 Institut für Informatik Betriebliche Informationssysteme 21
  • 22. Bestandteile der openArchitectureWare-Distribution • • • • • Institut für Informatik Betriebliche Informationssysteme 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) © Universität Leipzig 2006 22
  • 23. Konfigurierung von openArchitectureWare • • • • • • Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 23
  • 24. Praktisches Beispiel • • • • • • • • • • • • Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 24
  • 25. Beispiel-Domäne: Elektronisches Meldewesen bei der Bundesbank (1) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 25
  • 26. Beispiel-Domäne: Elektronisches Meldewesen bei der Bundesbank (2) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 26
  • 27. Analyse der Domäne Meldewesen (1) • • • Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 27
  • 28. Analyse der Domäne Meldewesen (2) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 28
  • 29. Festlegung der Zielplattform • • Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 29
  • 30. Definition des Metamodells • Institut für Informatik Betriebliche Informationssysteme mittels Ecore-Editor lässt sich das Metamodell erstellen und mit Hilfe EMF Class Diagram Editor darstellen © Universität Leipzig 2006 30
  • 31. Generierung des Modell-Editor Institut für Informatik Betriebliche Informationssysteme • • • © Universität Leipzig 2006 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
  • 32. Anlegen eines neuen Modells Institut für Informatik Betriebliche Informationssysteme • • • © Universität Leipzig 2006 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
  • 33. Modell im Workflow referenzieren Institut für Informatik Betriebliche Informationssysteme 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] © Universität Leipzig 2006 33
  • 34. Templates definieren • • • Institut für Informatik Betriebliche Informationssysteme 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>> © Universität Leipzig 2006 34
  • 35. Extensions definieren • • • • Institut für Informatik Betriebliche Informationssysteme 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» © Universität Leipzig 2006 35
  • 36. Checks definieren • • • • • Institut für Informatik Betriebliche Informationssysteme 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; © Universität Leipzig 2006 36
  • 37. Recipe definieren • • • • Institut für Informatik Betriebliche Informationssysteme 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; } } } © Universität Leipzig 2006 37
  • 38. Beispiel-Workflow Institut für Informatik Betriebliche Informationssysteme <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> © Universität Leipzig 2006 38
  • 39. Vergleich mit Vorgängerversionen • • Institut für Informatik Betriebliche Informationssysteme Verbesserungen gegenüber openArchitectureWare 3 openArchitectureWare 3 Generator Framework © Universität Leipzig 2006 39
  • 40. Verbesserungen gegenüber oAW 3 Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 40
  • 41. openArchitectureWare 3 Generator Framework Institut für Informatik Betriebliche Informationssysteme Funktionsweise des openArchitectureWare 3 Generator Frameworks ([MDSD*05], S. 57) © Universität Leipzig 2006 41
  • 42. Codegenerierungsverfahren • • • • • • • Institut für Informatik Betriebliche Informationssysteme Templates und Filters Template und Metamodell Frameprozessor API-basierte Generatoren Inline-Generierung Code-Attribute Code-Weaving © Universität Leipzig 2006 42
  • 43. Codegenerierungsverfahren (1) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 43
  • 44. Codegenerierungsverfahren (2) Institut für Informatik Betriebliche Informationssysteme 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 © Universität Leipzig 2006 44
  • 45. Fazit Institut für Informatik Betriebliche Informationssysteme • • • • • • • 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 © Universität Leipzig 2006 45
  • 46. Literatur • • • • • • • • • • • Institut für Informatik Betriebliche Informationssysteme [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 © Universität Leipzig 2006 46