The separation of concerns is a fundamental principle that allows to build a software with separate parts, thereby improving their maintainability and evolutivity. Executable models are good potential representatives of this principle since they capture the behavior of a software-intensive system, that is, when, why and how calling business operations, while the latter are specified apart. EMF is the de facto framework used to create an executable DSL (xDSL) but a solution to weave business operations into it is still missing. This is compounded by the fact that such business operations can be tied to specific technological platforms that stand outside the EMF world (e.g. Android SDK). To that purpose, in this paper we describe a solution for managing business operations both at design-time (creation of executable models with EMF) and at run-time (operation calls from the deployed execution engine). This solution is generic enough to be integrated into any Java-based environment and for any xDSL.
Executable modeling (Xmodeling) is receiving increasing attention, and hence creation of Executable Domain Specific Languages (xDSL) is centerstage. Executable models can be used for simulation purpose with mock data and operations, but they may also be deployed onto real devices. In that case, the formalism of the DSL captures the behavior of a system, while an embedded execution engine is responsible for the proper call of business-level operations (APIs) provided by the targeted platform.
For example, each elevator has its own firmware responsible for opening and closing doors, winding/unwinding the cable to reach a given floor. The actions of the elevator may be triggered according to a set of states and transitions preferably modeled through a finite state machine formalism. As another example, a travel booking system running on a server inserts customers information into a database or call Web services provided by air transport companies. The behavior of such a system specifies when these business routines have to be executed and under what conditions. The calls to the various Web services may be orchestrated through a BPEL or BPMN formalism.
However, a problem arises when using and creating an executable DSL (xDSL) for using such executable models: the data flow management. Writing a piece of code in a classic way consists in weaving a control flow with a data flow. Let’s consider these basic lines of Android-inspired Java code: 1 3 5 . . .
C u r s o r sms = smsManager . g e t A l l S M S ( ) ; S t r i n g j s o n = cloudManager . c u r s o r 2 J S O N ( sms ) ; cloudManager . s a v e ( j s o n ) ; . . .
The first line of code retrieves all the SMS stored into the smartphone. Then, this set of SMS is passed as parameter to a second method converting them into a neutral JSON format. Finally, in the last line of code, this JSON contents is saved in a Cloud. The control flow consists here in the definition of the sequence of the method calls and on which object they are called (here smsManager or cloudManager). The data flow consists in passing parameters to the methods and getting the resulting objects that could be further parameters of other methods. Here for instance, the object named "sms" is obtained by the first method call and passed as parameter to the second method. Of course, depending on the business methods, the number and type of parameters can vary as needed.
As an example of xDSL for applying our solution for managing business operations, we have defined a simple DSL using EMF: PDL for Process Definition Language. A process is composed of a set of ordered activities. The idea is that business operations can be associated with each activity. For our Android example, this will lead to define a PDL model with a sequence of three activities, one for each line of code. From now on, the control flow is reified in the form of a PDL model and the software engineer is only in charge of implementing the business operations. This is the execution engine of PDL that will carry out the complete execution of the model: once the business operation of an activity is finished, it goes to the next activity and executes its business operation and so on till the end of the process.
However, an important problem remains: how to define the data lfow? How does one set for an activity which is the operation to be called, on which Java business object and with which parameters? How does one store the result of an operation to reuse it afterward as a parameter of the operation of another activity? This problem is not specific to our PDL language but is a recurrent problem when defining xDSL where executable elements are associated with business-level operations. In this paper, we propose a generic solution for managing a data flow during the definition of any xDSL. It is composed of a set of meta-classes that can be added in any Ecore metamodel to define a data flow and a set of EMF Java classes that are used to define the execution engine thereof and that will manage automatically the execution of business operations. This solution is delivered as an Eclipse/EMF plugin called Xmodeling Studio 1.
We took Android as an example because development of an Android application requires the Android SDK and the Android Studio IDE, and it can certainly not be achieved in Eclipse/EMF. In this paper, we describe the integration of the execution engine of a xDSL defined with Xmodeling Studio and how to use its executable models in any Java-based development using any IDE. We are convinced that being able to push xDSL and models into mainstream software development (independently of Eclipse/EMF) can lead to a wider adoption of MDE.
The rest of this paper is organized as follows. In Section 2 we describe how a language engineer implements a xDSL, its metamodel and execution engine, using Xmodeling Studio. In Section 3, we explain how a software engineer uses the xDSL defined in any Java development. Before concluding, we discuss related work in Section 4. 2
In this Section, we explain how a language engineer can create a xDSL using Xmodeling Studio with associated business operations. As an example, we first define PDL which Ecore meta-model is depicted on Figure 1. Roughly, a process is composed of a set of activities, has a first and a last activity, and all these activities are ordered through their next/previous references. The reference currentActivity in Process enables to know which is the current active activity when the model is interpreted by the engine. The meta-classes Xmod_Action and Xmod_Operation (in green) are not part of the PDL definition. They are meta-classes automatically added by Xmodeling Studio for managing business operations as we explain in the following. 2.1
The main idea is at run-time to tag the Java objects that will be either parameters or return values of business methods and also the objects on which the methods are called. The pairs tag/object are then put in a Java map (java.util.Map) that will be used by the execution engine to retrieve the objects, as we will see in the following.
A business operation (i.e. a plain Java method in the code) is defined with the meta-class Xmod_Operation. It has a method name, a set of parameters, a possible return value and the object on which it will be executed. This information (excepting the method name) corresponds to the tags of the Java objects in the map.
The meta-class Activity from PDL metamodel specializes Xmod_Action. This is how the business operations are added on metaelements. We have leveraged the semantics of UML state machines for associating business operations as for an UML state: on entry, on exit and the do action. For almost all xDSL, the execution semantics consists in activating elements and deactivating other ones: 1The tool is available at this address: http://www.pauware.com/xmodeling from a state to another one when following a transition, from an activity to the next one when the current activity is finished. . . So, these notions of entering and exiting an element can be generalized to any xDSL. The three operations are optional. However, if one does not want to follow our pattern, the operations link between Activity and Xmod_Operation enables to add operations and to execute them as desired within the execution engine.
The link between our generic meta-classes and those of an Ecore metamodel can be made in two ways with our Eclipse plugin. If you have an existing metamodel, you have to annotate some metaclasses: by "Xmod_main" for the root element of the Ecore metamodel (that will help in the code generation as explained further) and by "Xmod_action" for elements that need to specialize Xmod_Action. Then, you launch a metamodel-to-metamodel transformation that will add our generic meta-classes at the right place in your metamodel. If you want to build a brand new xDSL, you create an "Empty Xmodeling project". This will create an EMF project with an Ecore metamodel containing our generic meta-classes. In both cases, in the "src-gen/" directory of the EMF project, the EMF code of our meta-classes will be placed including the built-in code for automatically executing business operations. 2.2
We provide the implementation of the EMF Java classes with the code that will automatically execute business operations. The main part of this implementation is the execute method of Xmod_Operation. Based on the tags, it first retrieves in the map the objects that will be the parameters of the method and also the object on which the method has to be called. Based on these objects and the method name, a dynamic call of the method is made trough the reflection mechanism of Java. If the method returns a value, it is put in the map with the right tag.
An utility class is also automatically generated for managing the map and the models. It is put for our example in the EMF generated PDL.util package and is called "PDLXmodUtil". This class contains static Java methods for: • Loading a model and getting its root element, based on the "Xmod_main" annotation put on one meta-class of the metamodel. In our example, this annotation has been put on the Process meta-class, so the generated method will have the following signature:
Process loadProcess(String fileName) • Saving a model through a root element, here again based on
the "Xmod_main" annotation • Getting and setting the object map • Loading and saving the in-memory object map through an
XML file
During the execution, saving the model and the map allows to save the complete current state of this application: both its behavioral state and the current contents of the business objects. It can be used to build an execution trace that can be afterwards analysed or to reload and restart the application at a given point in time.
However, depending on the size and number of the Java objects in the map and on the size of the model, such loading and saving can be heavy-load operations and then should be used sparingly. 1 / / c r e a t e t h e i n i t i a l c o n t e n t s o f t h e map with b u s i n e s s
/ / o b j e c t s on which methods w i l l be c a l l e d 3 HashMap< S t r i n g , Object > map = new HashMap < > ( ) ;
SMSManager smsManager = new SMSManager ( . . . ) ; 3 IMPLEMENTATION OF A SOFTWARE WITH 5 CloudManager cloudManager = new CloudManager ( . . . ) ; map . put ( " sms " , smsManager ) ;
A XDSL 7 map . put ( " c l o u d " , cloudManager ) ; 3.1 Business code and executable model 9 // // lgoeande r taht eed c ount ti elinttasr yo f ctlha es s PDL model through our Once the language engineer has released its xDSL, any software P r o c e s s proc ; engineer can used it to create a software. He/her has to provide 11 proc = PDLXmodUtil . l o a d P r o c e s s ( " SMSBackupWorkflow . xmi " ) ; an implementation in Java for the business operations (getAllSMS, / / s e t t h e map through our g e n e r a t e d u t i l i t a r y c l a s s cursor2JSON and save for our Android example). This develop- 13 PDLXmodUtil . setMap ( map ) ; ment can be made in any Java environment. Then, using EMF, he/she defines the executable PDL model. If using a textual syntax 2This concrete syntax has not yet been implemented for PDL. Currently, the PDL model is created using the EMF generic XMI file editor as presented on Figure 2.a. 13 15 11
Thanks to this generic code, the implementation of the execution engine for PDL is straightforward. It consists mainly in implementing the executeProcess method of Process within the EMF generated code: created with Xtext2, it will give the model of the Figure 2.b for our Android example. It defines a sequence of three tasks each one associated with one business operation (on entry for the two first and on do for the last one). The "on" enables to express on which object (its tag) the operation will be called, "result" the tag of the returned object of the operation. We can notice the tag "allSMSContent" is the result of the operation of the first activity and is passed as parameter for the operation of the second one. In the same way, the result of the second activity tagged "json" is passed as the parameter of the operation of the last activity. This way, the data flow among activities is automatically managed and our generic implemented EMF Java classes will manage the Java objects at run-time through their tags.
For the software engineer building a business application, once its PDL model defined, he/she has to write a code that will initialize the contents of the map and then launch the process execution. For instance, for our small example, it will be something like this: (a) abstract syntax
(b) textual concrete syntax Unlike EMF standalone deployment which is done typically exporting as RCP Application, we need a custom, minimal deployment.
Indeed, the interpreter has no graphical user interface: it is rather an autonomous executable JAR, able to take XMI files as inputs; provided they conform to the metamodel of the given xDSL. The core libraries coming from EMF that must be isolated from the rest are: • org.eclipse.emf.common.jar • org.eclipse.emf.ecore.xmi.jar • org.eclipse.emf.ecore.jar • org.eclipse.ocl.pivot.jar
In addition, the package of the ANTLR Parser generated by Xtext can be embedded so that a concrete textual syntax is also supported as input. The lightweight, low-dependency and lowmemory footprint criterion must drive the deployment phase so that the interpreter is truly embeddable in tiny devices like Android smartphones for example (the four above packages have a total size under 5 MB and even under 2 MB without the OCL run-time verification package).
As a proof of concept, we have successfully implemented a simple Android application with Android Studio using PDL 3. It basically requires to add in the project the EMF JAR files listed just above, 3Sources and technical details are available on http://www.pauware.com/xmodeling/ android-example.html the JAR generated from the EMF classes for PDL including the code of the PDL execution engine and of our generic code for managing the data flow. The SMSBackupW ork f low .xmi file has also to be put in the project. 3.3
At a glance, this way of programming is more complex and less convenient than the classic way but this is due to the basic application example and the choice of a minimalist metamodel as a xDSL example. Our PDL simply executes one sequence of activities and our Java example is a sequence of lines of code. Consequently, in both cases, the behavior is reifed under the concept of sequence. Then, the xDSL does not ofer a more high-level and abstract way to define the behavioral part of an application. But let’s imagine an extension of PDL with parallel sequences and forks or joins among them. In this case, writing by hand in Java an application following this behavior (such as a method that must wait the end of several parallel methods to be executed) will be a headache whereas it will be straightforward and much quicker using the extended PDL formalism as simply requiring to define a model. This highlights the interest of using xDSL for defining the behavior of an application. Another benefit of such an approach is that changing the behavior of the application is simply made by modifying the model and does not require to change any line of Java code (except business operations of course).
Using a map requiring to put in it all the objects used as parameters, return values and target objects of the business methods seems to be fastidious. But if you are using coarse-grained business actions, once the initialization of the business objects on which the operations will be called is done and that they have been put in the map, the data flow is automatically managed: results of activities will mainly be the entries of other ones as defined in the high-level executable model. It will not be necessary to put many other objects in the map. 4
Several recent research initiatives have been launched to help in
building executable DSLs and associated tools. The GEMOC
Studio [
Of course business code can be integrated during the software
development and even legacy code when using these tools. For
instance, [
[
fUML is used in previous citations as a language for defining the
semantics of a modeling language, i.e. at the metamodeling level,
but it has been released originally for defining the equivalent of
a programming code in UML models. One can then design for an
application the class diagrams, state machines, sequences diagrams
and any required diagrams and then add the contents of the class
methods in fUML either through a kind of activity diagram or
using a pseudo-code syntax thanks to ALF [
At the complete opposite of these full-modeling approaches but
still in making a clear separation between the behavioral and the
business parts, there is a tool such as PauWare5 [
In this paper, we propose an intermediate and pragmatic approach where the behavioral part of an application is defined with an executable model and the business part is defined by the software engineer in plain Java. This allows him/her to reuse directly existing code and to use the IDE he/she prefers or the one that is required such as Android Studio when developing Android mobile applications. We propose tools and techniques to glue these behavioral and business parts together through automatic code generation, for any executable DSL. 5
In this paper, we have presented a solution for weaving business operations into executable elements of any xDSL. Inspired by the semantics of UML state machines, business operations are associated with an executable element on entry (when it is actived), on exit (when it is deactivated) and as a do action (when running). We provide generic meta-classes for defining business operations that can be automatically added to any meta-model. We also provide boilerplate EMF Java classes for these meta-classes that contain a generic code carrying out the automatic execution of the business operations through the Java reflection mechanism and helping in the implementation of the execution engine of a xDSL. At run-time, the Java objects (business objects, method parameters or returned values) are put in a map. Our generic code will access to this map to get or set the required objects for an operation execution. This enables to manage the data flow among operations while the control flow is reified within the executable model. This solution is available trough an Eclipse/EMF plugin called Xmodeling Studio.
The originality of this solution is that it is mixing modeling and programming for an easier integration of MDE into everyday software developments within the Java ecosystem. Whilst defining a xDSL for simulation does not required business code, for a concrete software development where using existing API or legacy code is unavoidable, the link between these business parts and the executable model must be made. The xDSL created with Xmodeling Studio, more precisely their execution engines, can be deployed independently of the targeted software or platforms: an Android application, a Web server, a desktop application, an Arduino program. . . This is due to the fact the executable model may reify any kind of application behavior, independently of the business operations required. They will be called by our generic EMF Java classes.
As perspectives, we will continue the development of Xmodeling
Studio with new features. As well-established, an executable model
contains static and dynamic elements [
The presented work is part of the MegaM@RT2 project
(Megamodeling at Runtime – Scalable Model-based Framework for
Continuous Development and Runtime Validation of Complex Systems)
[