Your SlideShare is downloading. ×
Using openArchitectureWare 4.0 in domain "registration"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Using openArchitectureWare 4.0 in domain "registration"

224

Published on

Some retro: This presentation dated 2006 shows how to do model driven software development with openArchitectureWare 4.0 in the example domain "registration". …

Some retro: This presentation dated 2006 shows how to do model driven software development with openArchitectureWare 4.0 in the example domain "registration".

Although openArchitectureWare is now superseded by Xtext, Xtend2 and Xbase it is always good to remember the principles of model driven software development.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
224
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×