Meta-object protocols are used to open up the implementations of object-oriented general-purpose languages to support semantic variability. They enable performing application-level semantic adaptations to the language even at runtime. However, such meta-object protocols are not available for domain speci c-modeling languages. Also, existing approaches to implementing domain-speci c modeling languages do not support semantic adaptations, where the application basically rede nes speci c parts of the language semantics. We propose a new approach for the implementation of domain-speci c modeling languages that uses metaobjects and meta-object protocols to open up the implementation of domain-speci c abstractions. This approach enables runtime semantic variability of the form of applicationspeci c late semantic adaptations of domain-speci c modeling languages that depend on the runtime application context.
D.3.3 [Software Engineering]: Language Constructs and Features|Classes and Objects, Frameworks ; D.2.11 [Software Architectures]: Languages
Domain-speci c modeling languages (DSMLs) facilitate the development of software in a certain application domain by providing direct means to express domain-speci c abstractions and operations. DSMLs are supported by domainPermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
First International Workshop on Composition and Variability colocated
with AOSD’2010 Rennes, St. Malo, France
Copyright 2010 ACM ...$10.00.
speci c interpreters or compilers, which implement DSML
syntax and semantics [
Previous work showed that most of the current methods
for implementing DSMLs are closed with respect to changes
in their semantics [
This approach allows DSML users to de ne the DSML
semantics that exactly ts their needs, in the spirit of semantic
variation points of UML2 [
In [
Let us now list and de ne what could be adapted in a DSML: A domain type is a type of the metamodel of the DSML, i.e. a type representing a domain abstraction. Adapting a domain type means that every instance created after the adaptation will have the new semantics. Domain types contain domain operations that may change the state of domain objects. A domain object is an instance of a domain type. Adapting a domain object means that the semantics (the implementation) of its domain operations (and only the operations of this particular object) are changed.
Existing approaches to implementing DSMLs (e.g. DSML
compilation [
Our contribution is a method to implement DSMLs which
are able to support runtime semantic adaptations.
Metaobject protocols (MOPs) are interfaces to change the
semantics of object-oriented programming languages [
To evaluate our approach, we instantiate the method by
building a DSML for state machines. This DSML supports
semantic adaptations discussed previously in literature [
The remainder of this paper is structured as follows. Section 2 presents di erent dimensions along which semantic adaptations may be de ned. The proposed DSML method is presented in Section 3. Section 4 evaluates the support for semantic adaptations of a DSML implemented following our method. Related work is discussed in Section 5. Section 6 concludes the paper and discusses future research directions.
It's not straightforward to adapt the DSML semantics at the application level. DSML programmers require analysis means to design their adaptations. Hence, we have identi ed the following dimensions of semantic adaptations. 2.1
The rst dimension along which we classify DSML semantic adaptations is the scope of variability. This dimension is discrete and has two values: (a) domain type semantic adaptation and (b) domain object semantic adaptation. A domain type semantic adaptation a ects the semantics of (D3.a) Pre-Execution
Semantic Adaptation --- DSL Loading +++ Adaptation +++ Adaptation %%% DSL Execution %%% %%% %%% %%% End of Execution (D3.b) Execution Context Dependent
Semantic Adaptation --- DSL Loading %%% DSL Execution %%% +++ Adaptation %%% +++ Adaptation %%% %%% End of Execution all domain objects of a given domain type. On the contrary, a domain object semantic adaptation a ects only one particular domain object. 2.2
The second dimension of semantic adaptations is the granularity of adaptations that are made. The size of these adaptations ranges from one single domain operation to multiple parts of the DSML semantics. Indeed changing one part of the semantics often requires also changing another part of the semantics, and multiple \elementary" semantic adaptations have to be packed into a unit of change. 2.3
The third dimension characterizes the relation between the point in time in which the semantic adaptations happen and the point in time when DSML programs are executed. In most cases, the right semantics for a program execution can be determined beforehand and stays xed for a complete program run. Sometimes, the selection of the right semantics depends on the execution state of a DSML program, i.e., a change in the DSML program context triggers a semantic adaptation.
Let us consider the following two abstract examples of execution traces that illustrate the two possible points in time when adaptations may take place. Figure 1 shows the di erence in the execution traces of a pre-execution adaptation and a context-dependent adaptation. In both traces, the rst step is to load the DSML program of which the corresponding trace is pre xed by \{ { {". Then, two kinds of execution steps can occur: semantic adaptation (\+ + +") and normal DSML execution (\% % %").
The left-hand side of gure 1 schematically depicts a preexecution semantic adaptation: the semantics of the DSML changes before any domain object is created, or any call to a domain operation has occurred. Note that multiple adaptations can be applied as indicated. Then, the DSML program is evaluated until completion. In this case, the adaptation is independent of the DSML execution. The right-hand side of gure 1 depicts an execution context-dependent semantic adaptation, as used in the running example. Unlike the previous trace, the adaptation happens during DSML execution, depending on the concrete values of domain objects. This is symbolized by the interlacing of several regular domain operation execution and semantic adaptation steps. Such context-dependent adaptations enable semantic selfadaptation of DSML programs.
This section presents a method for implementing DSMLs. DSMLs interpreters implemented with this method have the particularity to allow late semantic adaptations (as described in 2), i.e. semantic adaptations of the DSML inside DSML programs. We use the Groovy programming language to demonstrate the feasibility of the approach, as well as to fully instantiate the approach later in section 4. 3.1
Groovy [
While our method for implementing DSMLs could be
implemented using other programming languages that come with
a meta-object protocol (Smalltalk [
Let us now give a quick overview of the features of Groovy
that our method uses for implementing DSMLs2. Every
Groovy object is bound to a meta-object [
Also, there is a registry that links a class name to its default meta-object. Every new instance of a class, say x, is bound to the meta-object for its class in the registry. Hence, when the registry is updated, already existing objects keep the old meta-object and the new generation of objects is bound to the updated meta-object.
Groovy supports rst-class closures. A closure can be created dynamically, passed as parameters to methods and functions, and executed. Listing 1 illustrates these points 1Note that users do not have to understand and use the MOP as long as they use the default semantics of a DSML and do not need to adapt it. 2Note that our approach is not bound to Groovy speci cally, but to dynamic languages with a MOP. For instance, our approach is completely applicable in the context of Ruby. 1 // creating a closure 2 aClosure = {x-> 3 print "hello "+x } 4 5 def m(Closure c) { 6 c("world") // executing the closure 7 } 8 9 // passing the closure as parameter 10 m(aClosure) 1 // creating a closure 2 aClosure = {-> bar() } 3 4 // two di erent contexts 5 class Context1 { 6 def bar() { println "bar" } } 7 class Context2 { 8 def bar() { println "bar2" } } 9 10 // executing the closure with Context1 11 aClosure.delegate=new Context1() 12 aClosure() // output "bar" 13 // executing the closure with Context2 14 aClosure.delegate=new Context2() 15 aClosure() // output "bar2"
Also, an important feature of Groovy closures is that their execution can be parameterized by a delegate context. By default, a closure has access to the lexical context in which it has been created. The lexical context contains all local variables of the closure. If it has been created within a method body, all variables available in the method are also available for the closure. In particular, all instance attributes and methods of the object that has created the closure are available when the closure is executed. This creating object is called the owner of the closure. In addition to the lexical context, the available context can be extended. When using a delegate for the closure, by changing its delegate attribute to refer to the delegate, the lexical context of the delegate becomes accessible in the closure. This way, the instance attributes and methods of another object than its owner can be used. If a function is not found in the closure's lexical context, a method with same signature is looked up in the delegate context, as shown in listing 2. Note that depending on the current binding of the delegate, the execution of the same closure can produce di erent results.
Technically, extending the available context for a closure is possible because Groovy uses a special meta-object for every closure. This meta-object rst tries to lookup attribute accesses and method calls in the lexical context of a closure, i.e., in the local variables and in the owner. If no attribute or method with a corresponding name or signature is available in the lexical context and if the closure's delegate attribute is set, then the meta-object tries to lookup the attribute or method in the class of the delegate object. Only if the attribute or method can be found neither in the lexical context nor in the delegate, Groovy throws a runtime error. 3.2
Our method is based on Hudak's method to implement
DSLs [
For instance, let us consider the implementation of the default semantics for a DSML for state machines. Figure 2 depicts the design of this DSML. The metamodel consists of classes Fsm, State, Transition, Actions. The Fsm class maintains a set of states, refers to a current state and implements some default semantics of state machines, e.g., the method receiveEvents(...) de nes the dispatch mechanism of events received by a state machine. State instances maintain a set of outgoing transitions and may have an on_entry action and implement the state semantics. For instance, the method handleEvent(...) de nes the state event handling mechanism. A Transition points to the next state. The fire(...) method is called whenever a transition is selected. The class Action encapsulates a set of domain-speci c actions; the semantics of an action execution is encoded in the doIt method. Finally, the syntactic language interface is implemented in class StateMachineDSML. There is a method in StateMachineDSML for each keyword in the DSML. When called, these methods instantiate domain objects.
Listing 3 shows an excerpt of an embedded DSML program for state machines. The DSML program is contained in the closure dslPackage (cf. line 3) which is con gured in line 22 to have an instance of StateMachineDSML as its delegate and whose evaluation starts at line 24. The evaluation is performed in two steps.
The rst step transforms the textual DSML program (from line 5 to 9), embedded into the host language syntax, to a representation as a network of interrelated domain objects (instances of the domain classes from the metamodel, e.g., the instance MyFsm of class Fsm). During the execution of the closure, keywords, e.g. fsm, state, and when, are encountered in the DSML program. These keywords are turned into method calls due to the exible syntax of Groovy. When using curly brackets at the end of a keyword method call, Groovy creates a closure and passes the closure to the method call as the last parameter. For instance, the program segment fsm 'MyFsm', {...} is turned into a method call of the form fsm('MyFsm', closure-inbrackets) with the dslPackage closure as the receiver. These calls are dispatched to closure's delegate, in this case a StateMachineDSML, of which the method with the corresponding keyword name and signature is called. These methods serve mostly as factories of domain objects. The second step, in line 14, is the execution of the DSML program as a method call to a domain object (resp. MyFsm and execute), given a speci c execution context ({'ok','error',...}). This triggers a cascade of method calls on domain objects created during the rst step. 3.3
In the following, we explain how to use meta-objects to enable late semantic adaptations. The meta-level introduced by our method is schematically depicted in Figure 3. Every domain type is mapped to a domain class A domain class, e.g., DomainClass in Figure 3, de nes the domain operations of its instances { the domain objects, e.g., aDomainObj. The semantics of domain objects is rei ed in meta-objects, which are responsible for handling the execution of domain operations. Every domain class is associated with a meta-object, which is the default meta-object of any new instance of the domain class. Meta-objects, e.g., x in Figure 3, dispatch method calls received by domain objects to concrete implementations of domain operations. The links meta-object and/or impl can be changed at runtime, which is the key to allow dynamic semantic adaptations.
New instances have default semantics before semantic adaptation
Our base embedding method in Groovy presented above supports this meta-level: 1) all domain classes are Groovy classes whose semantics can be modi ed at runtime; 2) all domain objects are Groovy objects, and the corresponding meta-object can be changed for a single instance only. 3.3.1
Figure 4 shows how the two kinds of variability with regard to the scope dimension { domain type versus domain object { are supported in the proposed meta-level.
The upper part shows the e ects of semantic adaptations whose scope is an entire domain type; the lower part corresponds to an adaptation that is speci cally scoped for a particular domain object, thus, only domain objects are shown there. Both parts show the relation between domain types and domain objects to their corresponding semantics (encapsulated in a meta-object) before and after the adaptation.
In the upper left quadrant, the domain type A is bound to the default semantics represented by the meta-object x. Every new domain object that is created, e.g., a, runs under the default semantics. The semantic adaptation de nes new semantics for domain type A. In the upper right quadrant, a new meta-object y is de ned to represent the new semantics and A is associated with it. Any domain object created subsequently runs under the new semantics: the domain object b is created after the adaptation, hence, it is linked to the new meta-object y. Objects that were created before the semantic adaptation continue to run under the previous semantics, e.g., a is still linked to the meta-object x.
In the lower left quadrant, the domain objects c and d are created with the same semantics. The object-level semantic adaptation depicted here modi es the semantics of d only. The lower right quadrant shows the domain objects, metaobjects, and their relations after the semantic adaptation has taken place. While c keeps the former semantics, d uses the new semantics represented by meta-object z. 3.3.2
Figure 5 depicts how adaptations at di erent levels of granularity are also supported by the proposed meta-level. The upper part shows the most ne-grained semantic adaptation at the level of an atomic domain operation. Unlike gure 4, the meta-objects are represented along with the domain operations. Doing so, we can highlight that the adaptation can separately impact a particular operation. In the upper left quadrant, the object a is attached to meta-object x; in the upper right quadrant, the same object is attached to a new meta-object y, which is the result of cloning x and binding foo to a new implementation, called fooImpl2. This way, the whole default semantics gets reused except the re-bound domain operation(s).
In general, it is likely that a semantic adaptation a ects several places in the default implementation of the semantics. Obviously, it is preferable to apply the changes together as a unit of semantic adaptation. In contrast to the atomic adaptation at the level of a single domain operation, in this case the changes have to be packed into a bigger variability unit. This abstract unit is depicted as the gray rectangle in the lower left part of gure 5. When an adaptation happens, all changes of this adaptation unit are performed in concert. The impacted domain objects are then bound to a new meta-object, which is the result of mixing the previous meta-object and the semantic adaptation unit. In gure 5, after the change, the domain object a is attached to the meta-object z, which binds both foo and bar to new implementations. 3.3.3
Semantic adaptations may occur at loading time or at runtime of DSML programs. Figure 6 depicts the sequence diagram of context-dependent semantic adaptation. Normal execution and semantic adaptation are interlaced. After loading DSML program the rst execution phase starts. In this phase, while executing the DSML program and when entering a context that requires a semantic adaptation, a special phase is started that consists of applying semantic adaptations onto domain objects (respectively domain types). At the end of the adaptation phase, control is passed back to DSML execution. The subsequent execution phase will run under the new tailored semantics. It is worth mentioning that several adaptation phases can be executed, e.g., the adaptation can be reverted or other semantics can be installed. 4.
This section discusses an implementation of a DSML for nite state machines (FSM DSML) using the method described in section 3. We show why the DSML interpreter supports semantic adaptations and how to implement them in at the level of DSML programs. 4.1
The UML speci cation [
Listing 4 shows two possible implementations of State's domain operation handleEvent. The rst implementation is the default one and encodes synchronous event handling; the second implementation supports asynchronous event handling. 1 // default: synchronous event handling 2 def handleEvent(Event e) { 3 this.fsm.currentState = 4 this.transitionSelection(e).fire() 5 } 6 7 // alternative: asynchronous event handling 8 def handleEvent(Event e) { 9 if (this.queue.isEmpty) { 10 this.fsm.currentState = 11 this.transitionSelection(e).fire() 12 } else { 13 this.fsm.queue.add(e) 14 } 15 }
Listing 4: Two Implementations of handleEvent 1 // default semantics: deterministic transition selection 2 def transitionSelection(Event e) { 3 return this.transitions.findAll(event).first 4 } 5 6 // alternative semantics: random transition selection 7 def transitionSelection(Event e) { 8 return this.transitions.findAll(event).getRandom() 9 } Listing 5: Two Implementations of transitionSelection 4.1.2
A given state of a state machine can have several transitions matching a given event. In this case, a state machine implementation has to provide a transition selection policy. Following our method, the semantics of transition selection is encoded in the transitionSelection method of the domain class State. Listing 5 shows two possible implementations of transitionSelection. The default implementation of the transition selection policy is a deterministic one. It returns the rst element of the collection of matched transitions. The alternative implementation selects a random item in the collection of matched transitions for a fairer loadbalancing.
The following sub-sections will discuss scenarios of using our method to apply alternative semantics for event handling and transition selection thereby varying the kind of adaptation along the three dimensions discussed previously. Section 4.3, speci cally, will discuss how to combine several variation points in one semantic module; for instance, how to use the tailored version of both handleEvent and transitionSelection in a concise and elegant manner. 4.2
Listing 6 shows the implementation of the rst dimension presented in section 3.3.1.
Listing 6 illustrates domain type semantic adaptation. The module dslPackage (lines 5-9) is a Groovy closure, which consists of three parts: (a) the declaration of a DSML program (lines 5 to 9), (b) a piece of meta-program that tailors the semantics of the DSML (lines 17 to 19), and (c) a piece of code that starts the execution of the DSML program (line 26). Parts (a) and (c) have been explained in 3.2. The adaptation consists in changing the transitionSelection method of the default state meta-object in line 17. As explained earlier, all instances of class State are a ected by this kind of adaptation and will execute with the tailored transition selection semantics.
For sake of space, we cannot elaborate on a complete DSML program that performs a semantic adaptation at the level of a single domain object. The code is similar to that in listing 6, except that it is not the metaClass of class State (line 17) that is changed but the metaClass of a domain object. For example, we can change the meta-object of S1 using MyFsm.S1.metaClass.transitionSelection = {...} . 4.3
This section illustrates the second semantic dimension, presented in section 3.3.2. On the one extreme in this dimension, a semantic adaptation a ects a single domain method; on the other extreme, a semantic adaptation may imply the construction of a completely new meta-object.
Listing 7 shows DSML code that is embedded similarly to listing 6. It focuses on the adaptation in lines 7 to 10. The only element that is changed is a domain method of a domain class.
On the contrary, listing 8 shows the creation of a semantic module and its use for tailoring the semantics of a domain class. Similarly to using classes to represent domain types, we use a new subclass for modularizing alternative semantics for a domain type. In the example, lines 2{9 dene such a subclass called TailoredState. Subclassing a domain type to create a new meta-object allows leveraging two key Groovy features used in listing 8: 1. The possibility to attach new semantics to an existing domain class, using a registry mechanism (line 13). 2. The automatic creation of a meta-object for each new class (line 14).
A meta-object for the new subclass is automatically created and stored in the class variable TailoredState.metaClass. In listing 8 lines 13{14, we register this meta-object also for the State class. As a consequence, the domain operation implementations of TailoredState will be used for State objects.
As shown gure 1, a pre-execution adaptation is simply a piece of code preceding the DSML program that changes the semantics of the language itself. While our method enables such adaptations, for sake of space, we cannot elaborate on them.
We now present a complete example of a semantic adaptation that occurs during the execution of a DSML program, i.e. a context-dependent adaptation. Consider now the selfadaptive DSML program in listing 9. This DSML program is a state machine representing a Web service composition for a travel booking process. The machine consists of two states, rst booking a ight and second booking a hotel. In both states, a call to a Web service is made in the on_entry blocks. States transitions are triggered by the reception of Web service responses.
This program is self-adaptive since it is able to recover from failing synchronous partners, thanks to our FSM DSML which supports semantic adaptations: the TravelPackage program is able: 1. to handle the error event in the BookingFlight state (line 12); 2. to replace the failing partner whith an asynchronous one (line 14) 3. to adapt itself to the new webservice by changing the event reception semantics of the DSML only for state BookingFlight in order to listen to asynchronous events (lines 12{21).
In this section, we have presented an instantiation of our method as a proof of concept that has shown its real implementability. From the viewpoint of end-users of our method, i.e. DSML designers, this section is fully complementary to the conceptual presentation of our method in sections 2 and 3 and enables them to implement on their own a DSML that supports late semantic adaptations. 5.
The implementation of DSMLs using \traditional, closed"
compilers (e.g. [
Our approach follows the domain virtual machine pattern
[
Steele [
Ramsey [
The initial method of embedding DSMLs by Hudak [
Meta-interfaces have been implemented for various
languages, e.g., 3-KRS [
There are no methods for DSML implementation available, that derive a MOP for the implemented DSML. The approach proposed in this paper is generic for class-based languages. Other dynamic languages that come with a MOP can be used to provide a exible DSML semantics as presented in this paper.
xPico [
A domain-speci c meta-object protocol for distributed
environment, called diMOP, has been presented in [
In this paper, we have presented a method for
implementing DSMLs that support semantic adaptations that may be
application-speci c and may occur as late as during the
execution of DSML programs. The proposal leverages
metaobjects [
As usual for dynamic approaches, there is a trade-o between adaptability and statically checked correctness. Our approach supports a maximal adaptability and may su er from possible correctness issues. For instance, DSML programmers who override part of the default DSML semantics might violate contracts and responsibilities that are implicit in the DSML design. These limitations will be addressed in future work. For instance, semantic adaptations may require adaptations in several domain classes and operations performed in concert. Our future work will also explore explicit contracts that can be checked at runtime to ensure the semantic consistency of adaptations. 7.