Modellbasierte Softwareentwicklung

Mit zunehmendem Fortschritt von Softwaresystemen ging im Zeitverlauf zugleich auch eine stei-gende Komplexität im Entwicklungsprozess einher. Beim Rückblick in die Vergangenheit ist als Strategie zur Bewältigung dieser Komplexität ein Trend zur fortwährenden Erhöhung des Abstrak-tionsgrades zu erkennen, der von der anfänglichen Nutzung von Maschinensprachen über Assem-bler, prozedurale und objektorientierte Sprachen bis hin zur aktuell bevorzugten Verwendung von Modellierungssprachen führt.¹⁷⁶

Unter einem Modell wird in diesem Kontext eine Menge von Aussagen über ein betrachtetes System verstanden.¹⁷⁷ Während bei der deskriptiven Modellierung lediglich ein untersuchtes Sys-tem mittels eines Modells beschrieben wird, stellt das Modell bei der präskriptiven Modellierung die vorgeschriebene Spezifikation für ein zu entwickelndes Systems dar, sodass dieses als Baustein erster Klasse in den Mittelpunkt aller Phasen des Softwareentwicklungsprozesses rückt und gar die Möglichkeit einer automatisierten Generierung des Softwaresystems bietet.¹⁷⁸ Vorzüge aus ei-nem solchen modellbasierten Ansatz ergeben sich insbesondere bezüglich Abstraktion, Wiederver-wendbarkeit, Interoperabilität und Domänen-Orientierung sowie einer verbesserten Qualität und Effizienz der Entwicklung.¹⁷⁹

Mit dem Begriff der modellbasierten Softwareentwicklung, englisch Model-Driven Software De-velopment (MDSD), werden demnach Techniken zur automatisierten Erzeugung ausführbarer Soft-ware aus formal spezifizierten Modellen bezeichnet,¹⁸⁰wobei die Formalisierung auf syntaktischer und semantischer Ebene stattfinden kann.¹⁸¹ Eine formale Spezifizierung bedeutet in diesem Kon-text die vollständige Beschreibung eines Aspektes der Software, um eine automatisierte Überfüh-rung in ausführbaren Code zu gewährleisten. Hierfür werden häufig UML-Modelle¹⁸²genutzt, aber auch weitere Alternativen, wie etwa das Eclipse Modeling Framework (EMF)¹⁸³oder XML-Modelle auf Basis von XML Schema¹⁸⁴bis hin zu textuellen Modellen basierend auf einer Spezifizierung in der EBNF (Extended Backus-Naur Form)¹⁸⁵, können je nach Vorlieben der Benutzer und Verfügbar-keit geeigneter Werkzeuge zum Einsatz kommen.¹⁸⁶

Domänenspezifische Modellierung

Im Rahmen eines konkreten Wissensgebiets, wie etwa der Ereignisverarbeitung in dieser Arbeit, kann für die Modellierung eine domänenspezifische Sprache, englisch Domain-Specific Language (DSL), zum Einsatz kommen, um mittels spezialisierter Ausrichtung ein erhöhtes Verständnis unter den Benutzern und verbesserte Ausdrucksmöglichkeiten innerhalb der Domäne zu erreichen.¹⁸⁷ Abbildung 4.2 illustriert in schematischer Darstellung den Bezugsrahmen einer DSL im Kontext der Modellierung.

176vgl. Gruhn u. a. 2006, S. 11–15

177vgl. Seidewitz 2003, S. 27

178vgl. Metzger 2005, S. 20; Gruhn u. a. 2006, S. 19 f.

179vgl. Gruhn u. a. 2006, S. 21 f.; Stahl u. a. 2007, S. 13–16

180vgl. Stahl u. a. 2007, S. 11

181vgl. Metzger 2005, S. 20

182vgl. OMG 2010a; OMG 2010b

183vgl. Steinberg u. a. 2008

184vgl. W3C 2012a; W3C 2012b

185vgl. ISO/IEC 1996

186vgl. Stahl u. a. 2007, S. 11 f., 31 und 64–75

187vgl. Gruhn u. a. 2006, S. 70

DSL

Modell Konkrete

Syntax

Abstrakte Syntax

Dynamische Semantik Statische Semantik Metamodell basiert auf

besteht aus

beschränkt besteht aus

repräsentiert

impliziert

gibt Bedeutung Domäne kennzeichnet

ist Instanz von

respektiert

erhält Bedeutung durch

verwendet Meta-metamodell

ist Instanz von

Abbildung 4.2:Bezugsrahmen einer domänenspezifischen Modellierungssprache¹⁸⁸

Die abstrakte Syntax stellt die Grammatik einer Modellierungssprache dar, indem singuläre Sprach-konstrukte und die Möglichkeiten ihrer Verbindungen zu neuen Konstrukten definiert werden, wo-hingegen die konkrete Syntax durch eine zugehörige Notation die lesbare Ausdrucksform der abs-trakten Syntax repräsentiert. Durch ihre Regelung der Wohlgeformtheit grenzt die statische Seman-tik einer Modellierungssprache die bedeutungsvollen Verbindungen von Instanzen der Sprachkon-strukte ein. Die tatsächlichen Bedeutungen der einzelnen SprachkonSprachkon-strukte und ihrer Verbindungen werden schließlich durch die dynamische Semantik determiniert.¹⁸⁹

Das Metamodell kennzeichnet auf diese Weise die betrachtete Domäne in formalisierter Form, indem die abstrakte Syntax sowie deren Beschränkung auf bedeutungsvolle Konstrukte durch die statische Semantik formal spezifiziert werden. Im Gegensatz zur zitierten Quelle¹⁹⁰ wird in dieser Arbeit die dynamische Semantik ebenfalls als Teil des Metamodells und nicht der domänenspezifi-schen Modellierungssprache (DSL) betrachtet, da sie der abstrakten Syntax des Metamodells unter Berücksichtigung der statischen Semantik eine Bedeutung gibt, ohne dabei von der verwendeten DSL abhängig zu sein. Überdies sollen gar mehrere Modellierungssprachen mit verschiedenen No-tationen auf demselben Metamodell basieren können, welches aber weiterhin dieselbe dynamische Semantik besitzen muss. Für einen eindeutigen Bedeutungsgehalt des Modells muss letztere klar definiert sein, kann allerdings auch in nicht-formalisierter Form vorliegen, etwa in natürlicher Spra-che. Die domänenspezifische Modellierungssprache (DSL) basiert auf diesem Metamodell und steu-ert eine konkrete Syntax bei, die dem Metamodell ein Erscheinungsbild gibt und auf deren Grund-lage letztlich modelliert wird. Ein mit diesen Mitteln erstelltes formales Modell verwendet somit

188in Anlehnung an Stahl u. a. 2007, S. 28, mit eigenen Anpassungen

189vgl. Petrasch und Meimberg 2006, S. 19–22

190vgl. Stahl u. a. 2007, S. 30 f.

die DSL, um die gewünschte Bedeutung auszudrücken, und ist zugleich eine Instanz von deren Me-tamodell. Die Definition des Metamodells erfolgt mit Mitteln eines Metametamodells, sodass sich eine dreistufige Schichtung von Metaebenen ergibt.¹⁹¹

Transformation von Modellen

Im Rahmen der modellbasierten Softwareentwicklung kann aus einem erstellten Modell, das in ei-ner formal spezifizierten DSL ausgedrückt ist, in automatisierter Weise lauffähige Software erzeugt werden, indem dieses entweder durch einen Interpreter zur Laufzeit eingelesen und direkt ausge-führt wird, wie beispielsweise formal beschriebene Geschäftsprozessmodelle in einem Business Pro-cess Management System (BPMS) wie in Abschnitt 2.1 beschrieben, oder durch einen Generator in Quelltext für eine spezifische Plattform transformiert wird.¹⁹²

Bei der Betrachtung von Transformationen von Modellen kann die von der OMG verantwortete modellbasierte Architektur, englisch Model-Driven Architecture (MDA), zur Klassifizierung heran-gezogen werden. Hier sind verschiedene Perspektiven für Modelle auf mehreren Abstraktionsebe-nen vorgesehen, wobei als wesentliche Transformation ein plattformunabhängiges Modell, englisch Platform-Independent Model (PIM), in ein plattformspezifisches Modell, englisch Platform-Specific Model (PSM) überführt wird.¹⁹³Es bietet sich demnach an, die DSL ebenfalls in einer plattformun-abhängigen Weise zu spezifizieren, um mit demselben als PIM beschriebenen Modell eine Transfor-mation auf verschiedene Plattformen zu ermöglichen.

Zu unterscheiden ist auf der Ebene des PSM zwischen Modell und Code, wobei letzterer als plattformspezifische Implementierung, englisch Platform-Specific Implementation (PSI), direkt in der genutzten Ausführungsumgebung lauffähig ist. Bei einer mehrstufigen Transformation kommt demnach zunächst ein Model-to-Model-Ansatz zum Tragen, bevor schließlich eine Model-to-Code-Transformation die tatsächlich ausführbare PSI generiert.¹⁹⁴

Für die abschließende Codegenerierung werden dabei häufig Schablonen genutzt, englisch Tem-plates, die zum Großteil aus einem Skelett mit statischen Codefragmenten bestehen, wohingegen an bestimmten Stellen in der Schablone sprachspezifische Markierungen, englisch Tags, als Platzhalter enthalten sind. Diese werden während der Codegenerierung dynamisch durch entsprechende Wer-te aus dem zu transformierenden Modell ersetzt. Eine Transformation mitWer-tels Schablonen eignet sich insbesondere im Falle der Generierung großer Mengen an statischem Code.¹⁹⁵

Konkrete Umsetzung in dieser Arbeit

Der Ansatz der modellbasierten Softwareentwicklung kommt in dieser Arbeit im Kontext der Ereig-nisverarbeitung zum Einsatz. Bei der Umsetzung der hierfür konzipierten DSL (siehe Kapitel 6), der sogenannten Event Processing Model and Notation (EPMN), wird für die Definition des Metamo-dells das Eclipse Modeling Framework (EMF) verwendet, welches auf den plattformunabhängigen

191vgl. Stahl u. a. 2007, S. 28–32

192vgl. Stahl u. a. 2007, S. 12 f.

193vgl. Brown u. a. 2005, S. 6 f.; Miller und Mukerji 2003

194vgl. Petrasch und Meimberg 2006, S. 125–128

195vgl. Stahl u. a. 2007, S. 146; Gruhn u. a. 2006, S. 172

Technologien XML und Java beruht sowie innerhalb der freien und quelloffenen Programmierum-gebung Eclipse¹⁹⁶eine umfassende Werkzeugkette für die modellbasierte Softwareentwicklung zur Verfügung stellt.¹⁹⁷EMF realisiert die wesentlichen Konzepte der MDA und liefert mit seinem zen-tralen Modell mit der Bezeichnung Ecore die Möglichkeit zur formalen Beschreibung von Metamo-dellen, wobei Ecore der Essential Meta Object Facility (EMOF) als Untermenge des von der OMG verantworteten Standards Meta Object Facility (MOF)¹⁹⁸zur Metamodellierung nahekommt.¹⁹⁹

Das zugrunde liegende Ecore-Metamodell wird für die Spezifizierung von abstrakter Syntax und statischer Semantik des Metamodells der DSL genutzt, hier der EPMN, und dient letzterer somit als Metametamodell.²⁰⁰ Abbildung 4.3 illustriert in vereinfachter Form in UML-Notation die wesentli-chen Elemente des Ecore-Metamodells, mit denen ein Ecore-Modell beschrieben werden kann.

name : String EClass

name : String EAttribute

name : String EDataType eAttributes

0..*

name : String

containment : boolean lowerBound : int upperBound : int EReference eReferences

1 eReferenceType 0..*

eAttributeType 1

eOpposite 0..1 0..*

eSuperTypes

Abbildung 4.3:Wesentliche Elemente des Ecore-Metamodells²⁰¹

Eine neue Klasse wird in Ecore alsEClassmodelliert, die über ihr internes Attributnameidentifiziert wird und beliebig viele modellierte Attribute und Assoziationen besitzen kann. In Ecore ist ebenfalls das geläufige Konzept der Vererbung umgesetzt, sodass für eine abgeleiteteEClassauch beliebig vie-le Basisklassen alseSuperTypesreferenziert werden können, deren Attribute und Methoden jeweils vererbt werden. Ein neues Attribut wird alsEAttributeerstellt, das anhand seines Namens identifi-ziert wird und über genau einen Datentyp der KlasseEDataTypeverfügt, wobei es sich sowohl um primitive Datentypen als auch um in Java definierte Objekt-Datentypen handeln kann. Zur Model-lierung von Assoziationen zwischen Klassen wird ^EReference verwendet, das über einen Namen verfügt und die Ziel-Klasse der Assoziation im AttributeReferenceTypeenthält. Anhand der Attri-butelowerBoundundupperBoundwerden die Multiplizitäten der verbundenen Klassen spezifiziert, während die Assoziation mittels gesetztem containment-Flag auch als Komposition definiert wer-den kann. Für eine bidirektionale Assoziation wird eine zweite EReference in entgegengesetzter Richtung erstellt, deren beideeOpposite-Attribute auf die jeweils andere Assoziation verweisen.²⁰²

196siehehttp://www.eclipse.org 197vgl. Steinberg u. a. 2008, S. 11–15

198vgl. OMG 2004, S. 31–40

199vgl. Steinberg u. a. 2008, S. 39 f.

200vgl. Stahl u. a. 2007, S. 71 f.

201in Anlehnung an Steinberg u. a. 2008, S. 105

202vgl. Steinberg u. a. 2008, S. 105 f.

Im Rahmen der EMF-Werkzeugkette kann ein mit diesen Mitteln beschriebenes Ecore-Modell in komfortabler Weise für die Weiterverarbeitung und Transformation in ausführbaren Code genutzt werden. Abbildung 4.4 veranschaulicht in schematischer Darstellung die eingesetzten Modelle zur Entwicklung mit EPMN und ihre Zusammenhänge auf den verschiedenen Metaebenen in vertikaler Richtung und verschiedenen Abstraktionsebenen in horizontaler Richtung.

Plaformspezifische Implementierung (PSI) Plaformspezifisches

Modell (PSM) Plaformunabhängiges

Modell (PIM) Metametamodell-Ebene

Metamodell-Ebene

Modell-Ebene

Code-Ebene

Ecore-Modell:

EPMN-Metamodell

Annotierte Java-Klassen Ecore-Metamodell

Ecore-Modellinstanz:

EPMN-Modell Java-Objekte

Esper-Modul mit EPL-Anweisungen miels MOFM2T

transformiert in repräsentieren

XMI-Modell

serialisiert repräsentieren

XML-Modell serialisiert

ist Instanz von

ist Instanz von sind Instanzen von

Abbildung 4.4:Zusammenhänge der Modelle für die Entwicklung²⁰³

Da das EPMN-Metamodell in Ecore spezifiziert wird, ist es eine Instanz des Ecore-Metamodells, wel-ches sich aus Sicht von EPMN auf der Metametamodell-Ebene befindet. Jedes Ecore-Modell und da-mit auch das EPMN-Metamodell wird in Form von XML Metadata Interchange (XMI) serialisiert.²⁰⁴ Hierbei handelt es sich um einen auf XML basierenden Standard der OMG zum Austausch von Meta-modellen, der unterdessen zu einem internationalen Standard von ISO (International Organization for Standardization) und IEC (International Electrotechnical Commission) gereift ist.²⁰⁵ Ein XMI-Dokument enthält alle spezifizierten Elemente des zugrunde liegenden Ecore-Modells und dessen vollständige Beziehungen, was im konkreten Fall dem Metamodell der EPMN entspricht.

Im Rahmen der EMF-Werkzeugkette wird ein solches Ecore-Modell üblicherweise mittels anno-tierter Java-Klassen umgesetzt, welche das Metamodell der DSL, hier der EPMN, in alternativer Form repräsentieren. Mit diesen Java-Klassen wird die Instanziierung eines EPMN-Modells letztlich durchgeführt, indem Java-Objekte mit den gewünschten Eigenschaften und Beziehungen aus diesen Klassen erzeugt werden, die sich auf der Modell-Ebene der EPMN befinden. Auch auf dieser Meta-ebene gibt es wiederum die Möglichkeit einer XML-basierten Serialisierung, wobei aus den

Java-203in Anlehnung an Stahl u. a. 2007, S. 62 f.

204vgl. Gronback 2009, S. 31; Steinberg u. a. 2008, S. 20 f.

205vgl. ISO/IEC 2005

Objekten nach den festgelegten Regeln der XMI-Spezifikation²⁰⁶ ein zugehöriges XML-Dokument durch einen verfügbaren Generator der EMF-Werkzeugkette erzeugt wird.

Aufgrund der plattformunabhängigen Ausprägung in Form von XML-basierten Serialisierungen von Ecore-Modellen stellt das Ereignisverarbeitungsmodell in EPMN im Kontext der modellbasier-ten Softwareentwicklung das PIM (Platform-Independent Model) dar. Gleichzeitig wird das EPMN-Modell durch ein Java-basiertes EPMN-Modell repräsentiert, welches demnach für das PSM (Platform-Specific Model) und eine tiefere Abstraktionsebene steht. Da das EPMN-Modell in informations-technischer Weise formal beschrieben ist, kann es automatisiert in die PSI (Platform-Specific Imple-mentation) auf der Code-Ebene überführt werden, welche direkt auf der verwendeten Ausführungs-plattform lauffähig ist und die unterste Abstraktionsebene darstellt.

In dieser Arbeit ist die CEP-Engine Esper als Zielplattform für die Transformation vorgesehen, bei der für die Definition von Ereignisverarbeitungsregeln die Esper-spezifische Event Processing Language (EPL) zum Einsatz kommt. Letztere basiert auf der Datenbankabfragesprache SQL, welche um erforderliche Echtzeitverarbeitungskonzepte erweitert wurde, um eine kontinuierliche Abfrage von Ereignisströmen zu ermöglichen.²⁰⁷Da diese Ereignisverarbeitungssprache eine rein textuelle Syntax mit einer Vielzahl an statischen Codefragmenten verwendet, wird für die modellbasierte Codegenerierung in dieser Arbeit das empfohlene Verfahren mittels Schablonen eingesetzt. In der EMF-Werkzeugkette kann hierfür die von der OMG standardisierte Modelltransformationssprache MOFM2T (MOF Model to Text Transformation Language)²⁰⁸ genutzt werden, die bei der Überfüh-rung von MOF-basierten Modellen in textuellen Code zum Einsatz kommt. Da sich Ecore und EMOF nahezu entsprechen, ist die Nutzung von MOFM2T für die Transformation des EPMN-Modells aus den jeweiligen Java-Objekten in ein Esper-Modul mit den entsprechenden EPL-Anweisungen zweckmäßig, zumal die Sprache in der EMF-Werkzeugkette zulänglich unterstützt wird.

MOFM2T arbeitet mit eingängigen Schablonen, welche die statischen Codefragmente unverän-dert enthält, während die dynamischen Platzhalter durch eine Markierung mit eckigen Klammern akzentuiert werden. Mittels Variablendeklarationen sowie der üblichen Kontrollstrukturen, wie et-wa Schleifen und bedingten Verzweigungen, lassen sich trotz der Einfachheit der Sprache ausdrucks-volle Transformationsschablonen formulieren.²⁰⁹

Im Dokument Eine Methode zur Entwicklung dynamischer Geschäftsprozesse auf Basis von Ereignisverarbeitung (Seite 68-73)