On The Refinement Of Model-to-text Transformations
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View On The Refinement Of Model-to-text Transformations as PDF for free.
More details
- Words: 5,574
- Pages: 12
On the Re nement of Model-to-Text Transformations Salvador Trujillo, Ander Zubizarreta, Josune de Sosa, Xabier Mendialdua
IKERLAN Research Centre, Spain {strujillo, ander.zubizarreta, jdesosa, xmendialdua}@ikerlan.es
Abstract. Model Driven Development (MDD) is a paradigm to automate the generation of code. A key artifact in this paradigm is a model transformation which de nes the mappings from a model to another model or even a code artifact. Although MDD was initially aimed at the generation of an individual program, shortly after appeared the need for families of programs. Hence, the combination of Model Driven and Software Product Lines (SPL) appears as a promising paradigm. Most of the previous work was focused on the necessity to support variability on models, but little work has been done so far on supporting the variability of remaining MDD artifacts such as model transformations or metamodels. This work rst motivates the need for variability of model transformations. We address then the application of step-wise re nement to model-to-text transformations expressed in MOFScript. We illustrate this with a case study.
Introduction Modeling is essential to cope with the increasing complexity of current software systems. Models assist developers during the entire development life cycle to precisely capture and represent relevant aspects of a system from a given perspective and at an appropriate level of abstraction. MDD is a paradigm to automate the generation of boiler-plate code. Raising the abstraction level enables to focus on the domain details and separate the implementation details. This brings a number of speci c bene ts such as productivity, reduced cost, portability, drops in time-to-market, and improved quality. Overall, the main economic driver is the productivity gain achieved, which is reported by some studies [14,19]. A key artifact in MDD is a model transformation that de nes the mappings between a model and another model or between a model and a code artifact. Although MDD was initially aimed at the generation of an individual program, shortly after appeared the need for families of programs. Researchers and practitioners have realized the necessity for modeling variability of software systems, where software product line engineering poses major challenges [25]. A software product line is a set of software intensive systems that are tailored to a speci c domain or market segment and that share a common set of features [5,21].
For example, in industrial software systems the presence of dierent types of subsystems (e.g., exclusive subsystems from dierent providers) implies that each is controlled in a similar though dierent way. This is typically achieved by de ning two features that are not necessarily present in all possible systems. A feature is an end-user visible behavior of a software system, and features are used to distinguish dierent software systems or variants of a software product line [16]. This impacts not only on the implementation, but on the modeling level. The modeling used in software product lines can be twofold. First, there are approaches for describing the variability of a software product line, e.g, there are feature models that specify which feature combinations produce valid variants [16]. Second, all variants in the product line may have models that describe their structure, behavior, etc. However, when dealing with variability in an MDD scenario, there are further artifacts apart from models that may need to cope with such variability. Model transformations are a case in point. In some scenarios, they may have too to cope with the variability imposed by the software product line. Hence, this paper takes a step back to study such impact into a broader perspective by analyzing the scenarios for Model Driven Product Lines. We shift our attention from the variability of models to a more general situation where the variability may embrace models, metamodels and model transformations. Hence, a realization of one feature may consist of variations of such artifacts. This work speci cally analyzes the variability of model transformations. The contribution of this paper is to apply step-wise re nement to model transformations. MOFScript-based model-to-text transformations are re ned by using XAK [1]. We illustrate our ideas with a simplistic case study, which is inspired on the industrial cases we work with. We begin by reviewing the background.
Background
Model Driven Development
is a paradigm where models are used to develop
software. This process is driven by model speci cations and by transformations among models or models and code. It is the ability to transform among dierent model representations that dierentiates the use of models for sketching out a design from a more extensive model-driven software engineering process where models yield implementation artifacts. This paradigm eases cumbersome and repetitive tasks, and achieves productivity gains. The main artifacts in MDD are models, metamodels and model transformations.
Models. Model is a term widely used in several elds with slightly dierent
meanings. A model represents a part of the reality called the object system and is expressed in a modeling language. A model provides knowledge for a certain purpose that can be interpreted in terms of the object system [17]. Typical
Fig. 1.
A simpli ed statechart for a temperature sensor
examples of models involve statecharts that represents the behavior of some functionality or class diagrams that show the structure of some code. Figure 1 shows a simple statechart model showing the behavior of a simple temperature sensor. The statechart has states
sClosed and sOpened in addition
to initial and nal states. Transitions between states and the conditions for these transitions are described in the model. The actions to be executed should be de ned too, but are omitted in the example.
Metamodels. A model is frequently considered an instance conforming to a
metamodel. A metamodel is a model of a modeling language where the language is speci ed [17]. In other words, the metamodel describes the elements of the domain and their relationships. A metamodel for a statechart might de ne its elements such as states, transitions, their relationships, etc. Note that the model in Figure 1 might conform to such metamodel. The mappings between metamodels are typically de ned by model transformations.
Model Transformations.
Model transformations play a pivotal role in
MDD because they turn the use of models for sketching into a more extensive model-driven usage where implementations can be directly obtained [23]. A model transformation is the process of converting one model to another model of the same system [20]. In general, a model transformation is the process of automatic generation from a source model to a target model, according to a transformation de nition, which is expressed in a model transformation language [17]. Depending on the target, model transformations can be model-to-model or model-to-text transformations. The former takes as input one or more models conforming to given metamodels and produces one or more models conforming to the same or another metamodels. The latter produces text as its output, that can be implementation code, documentation, or any other textual form. Model-to-model transformations usually make use of rules that are de ned as mappings between input and output metamodels. Model-to-text transformations combine rules with text templates that de ne the form of the output text.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
t e x t t r a n s f o r m a t i o n b a s e T r a n s f ( i n s c : " h t t p : / /www. w3 . o r g /2005/07/ scxml " ) { var o u t p u t F i l e : S t r i n g s c . ScxmlType : : main ( ) { f i l e ( outputFile ) writeSwitchStart () s e l f . s t a t e −>f o r E a c h ( s : s c . StateType ) { s . generateSwitchCases () } writeDefault () writeSwitchEnd ( ) } module : : w r i t e S w i t c h S t a r t ( ) { / ∗ Empty r u l e : t o be r e f i n e d l a t e r on ∗ / } }
/ ∗ Content o m i t t e d ∗ /
Fig. 2.
Example of a model-to-text transformation using MOFScript
There is a variety of open-source and commercial tools and languages for model
1
transformations . Our case study focuses on model-to-text transformations de ned using MOFScript transformation language. MOFScript language is a metamodel-independent language that allows to use any kind of metamodel and its instances for text generation. MOFScript tool is based on EMF and it is available as an Eclipse plugin. The de nition of a MOFScript transformation consists of rules. Figure 2 shows a base transformation de nition for transforming a statechart model into textual code. Implementation-wise, a transformation module called
baseTransf
is de ned. Such module is composed by several rules. They can have a context
2
type scoping to which metamodel elements can be applied such rules .
On the Need for Variability A Model Driven Development scenario typically involves models, metamodels and model transformations. Next, we analyze the need for variability of model transformations.
1
2
ATL [4], RubyTL [7], ATC [24] and other tools are for model transformations. Though these tools may be also used (and so we do) for model-to-text transformations, we focus on MOFScript since it is specialized on model-to-text. The execution of the transformation in Figure 2a starts with the sc.ScxmlType::main() rule. This rule is applied to the context type scoped by the type ScxmlType where sc is the input model. That means that it applies to every ScxmlType in sc. The output text le is de ned with file().
Scenario.
There are dierent scenarios when combining MDD and SPL.
Consider the dierences on the modeling language used: it is not the same to use UML or a Domain Speci c Language (DSL). There are scenarios where model variability may be enough and the variability of model transformations may not be needed. This may happen in situations where the used metamodel is standard and so it is not subject to variability. For instance, when using a UML class diagram, it seems unlikely to make its metamodel variable since it is somehow standardized. This may apply generally to the metamodels within the UML. A similar situation occurs when the model transformations come from a common library of model transformations that are shared. For instance, consider the dozens of model transformations expressed in
3
ATL that are available online . Therefore, in scenarios with standard metamodels and/or shared transformations, the use of model variability seems enough and thus variability of model transformations may not be needed. However, there exist other scenarios where the variability of model transformations may be needed. Consider the case in which dierent models and model transformations may need to be customized for dierent targets. Model transformations share a significant common part while diering in some variable parts. For instance, dierent implementation code can be generated from the same source model. The target code is expected to be executed in dierent platforms with dierent programming languages. This situation could be well handled by de ning features of the software product line. There is a large proportion of shared code and some particularities are bound to each programming language. In such situation, the application of variability to model transformations may enable to handle those dierences in a unique model transformation. Next, we illustrate this with our case study.
Case Study.
Although this motivating scenario is realistically more likely
to occur within a larger system, we illustrate our ideas with a family of control software systems developed following MDD. Particularly, we focus on the control of a simple temperature sensor that opens/closes some device (e.g. water pump). Our motivating scenario demands to cope with the variability of models, metamodels and model transformations. The les used in this example are available
4
online . Consider a model of a simple state machine and a model-to-text transformation de nition to get implementation code from it. The aim is to generate a switch statement implementing the statechart model. There are however dierent target platforms for the generated code. Such dierent programming languages are Ada and Java. Switch statements dier from Ada to Java. Actually, Ada does not provide a proper switch statement, but a case statement with equivalent structure and behavior to Java's switch. It would be possible to de ne a separated and independent model transformation de nition for each target language. In that way, however, it would be
3 4
http://www.eclipse.org/m2m/atl/atlTransformations/ http://www.ikerlan.es/softwareproductline/jisbd2009examples.zip
necessary to de ne a new transformation de nition for each new target language we would like to generate code for. Doing so, no reuse will be achieved. The structure of the switch statement is similar in most of the programming languages. Its dierence mostly lies in the syntax. Hence, it would be possible to de ne a base transformation common for all target platforms and to re ne it with partial or re ned transformations incorporating target speci c elements. This is what we called in this work as the re nement of model-to-text transformations.
Re nement-based Variability The re nement of model-to-text transformations is introduced in order to enable their customization for dierent variability needs. In our example, there is a statechart as a source model, Ada and Java as target programming languages and a model-to-text transformation with variability incorporated to connect the source with dierent targets. As a case in point, we considered the generation of switch statements that implement the code of a statechart model. Although switch statements are commonly found in most of current programming languages, they are not exactly de ned in the same way. In our example, we de ne a base transformation with all the common elements of the switch, that will be re ned for each output language. There will be a transformation re nement associated to each target language, each adding its speci c elements.
Base of a Transformation 1 2 3 4 5 6 7 8 9 10 11
<MOFScriptModel:MOFScriptSpecification . . . x a k : a r t i f a c t=" b a s e . m2t . model . m o f s c r i p t " x a k : f e a t u r e=" baseTrans ">
Fig. 3.
Base Transformation (XMI representation)
A base transformation de nition has been de ned with MOFScript (see Figure 2). This de nition takes a statechart model as input, and has the rules to generate a switch statement as output. Since the switch statement diers among dierent languages, this base transformation only has the common elements.
In our example, the base transformation de nes some common rules to generate a switch statement based on the statechart model. Some rules for writing the output are de ned (e.g.
writeSwitchStart)
but they are empty due to the fact
that the output text varies depending on the syntax of the output programming language. In the base transformation a variable named
outputFile
is de ned
too, to specify the name of the output le, but this variable is not yet given a particular value. The assignment will be done with a re nement, which will assign a name related to its output language later on. MOFScript allows to represent a transformation de nition as a model, conforming to the MOFScript metamodel. Figure 3 shows the model representation of the transformation using XML Metadata Interchange (XMI). (Note that this gure is equivalent to the textual representation of the transformation in Figure 2.) The transformation module is de ned with the
element. Nested to this element, variables, parameters and rules are de ned using the
, <parameters>
and
elements,
respectively. Actually, the base transformation can not be executed standalone since it is not complete, so it may not generate the expected implementation. The base transformation needs to be re ned for each output language.
Re nement of a Transformation
1 2 3 4 5 6 7 8 9 10 11 12 13 14
< x a k : r e f i n e s x a k : a r t i f a c t=" b a s e . m2t . model . m o f s c r i p t " x a k : f e a t u r e=" adaDelta " . . . > <x a k : e x t e n d s xak:module=" oFileModule "> <x a k : s u p e r xak:module=" oFileModule "/>
Fig. 4.
XAK-based Re nement of a Transformation
A re nement can be deemed of as a function that takes an artifact as an input, and returns another similar artifact which has been leveraged to support a given feature [3]. XAK is a language for de ning re nements in XML documents and provides a composer tool for them [1]. We used it for representing and composing our MOFScript-based transformations. MOFScript oers the option to represent
a transformation de nition as a model. Such model can be represented using XMI. Therefore, XAK can be used for re ning such transformations. Any traditional XML document can be a base document, but some addi-
@xak:artifact @xak:feature are added to the document root element. The rst one spec-
tional annotations are needed (see Figure 3). The attributes and
i es the name of the document that is being incrementally de ned, while the second one speci es the name of the feature being supported (base for base documents). To specify which elements are modularizables,
@xak:module is used.
That is, it indicates those elements that play the role of modules, and henceforth can be re ned. In general, a XAK module has a unique name. Re nement documents re ne base documents and they have
<xak:refines>
element as root (see Figure 4). Its content describes a set of module re nements
xak:module attribute) extending a given base xak:artifact attribute). The xak:super node is a marker
(i.e. elements annotated with the document (i.e. the
that indicates the place where the original module body is to be substituted. In general, a XAK re nement document can contain any number of
xak:module
re nements. Those elements of the transformation that can be re ned must be de ned before re ning such transformation. In our example, the re nement units are the transformation de nition itself, variables and rules. That is, we can add new rules or variables to the transformation de nition, we can add or set values to variables already de ned, or we can extend existing rules with new statements.
xak:module attribute to, elements to specify that they are modularizables (see Figure
We add and
3). Note that not all elements are modularizable, but only those we designate beforehand by
xak:module.
Figure 4 shows a re nement for the base transformation. This re nement re nes the base transformation de nition to generate the code in Ada programming language. Some of the rules in the base transformation are re ned adding Ada speci c elements. The variable
outputFile is given a value. The rules that 5
are re ned are those which are used to produce speci c code to the output le . Since the syntax diers between languages, those rules must be re ned for each language.
Composition of Base and Re nements XAK composer tool is used to compose the re nement to the base transformation, executing the following command:
> xak -xak2 -c baseTrans.mofscript adaDelta.xak -o composedAdaTrans.mofscript
5
Due to the lack of space, in the gure only the re nement of the rule writeSwitchStart is shown. The complete example is available for download at http://www.ikerlan.es/softwareproductline/jisbd2009examples.zip
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
<MOFScriptModel . . . >
1 2
/ ∗∗
3 4
∗/ texttransformation baseTransf ( i n s c : " h t t p : / /www. w3 . o r g /2005/07/ scxml " ) { var o u t p u t F i l e : S t r i n g = " example . adb " ;
5 6 7 8 9 10 11 12 13 14
∗ T r a n s f o r m a t i o n Generated by
MOFScript2Text transformation
/ ∗ Content o m i t t e d ∗ / module : : w r i t e S w i t c h S t a r t ( ) { " c a s e s t a t e i s \n " } / ∗ Content o m i t t e d ∗ / }
(a) Fig. 5.
tation
1 2 3 4 5 6 7 8 9 10 11
(b)
Composed Transformation: (a) XMI representation; (b) MOFScript represen-
case s t a t e i s when s C l o s e d => i f isWarm then
s t a t e := sOpened ; end i f ; when sOpened => i f i s C o o l then s t a t e := s C l o s e d ; end i f ; when others => end case ;
1 2 3 4 5 6 7 8 9 10 11 12 13
switch ( s t a t e ) { case s C l o s e d : i f ( isWarm ) { }
s t a t e = sOpened ;
break ; case sOpened : i f ( isCool ) { }
}
state = sClosed ;
break ; default :
(a)
(b) Fig. 6.
Generated code: (a) Ada; (b) Java
The result of the composition is a composed transformation model (Figure 5a), which can be executed directly giving as input the statechart model, or can be converted to a MOFScript transformation de nition le (Figure 5b) using that option in MOFScript tool and then executed. Note that some rules that were empty in the base transformation de nition, have now some body specifying how the output has to be in Ada programming language. So, the customization of model transformations is achieved. The output of the transformation is the
example.adb le which has the switch statement according to our model, written in Ada syntax (Figure 6a). Another possible re nement may be to re ne the base transformation de nition to generate Java code. In this case, the rules should be re ned to generate Java code. Although the structure of the generated code is almost the same, the syntax diers from Ada to Java. Additionally,
break; sentences are necessary in
Java, so a new rule needs to be added to the base transformation to write such sentences. The new rule will be called from
generateSwitchCases
rule, that
need to be re ned to add the new statement. Figure 6b shows the code obtained when running the transformation re ned for Java. The use of re nements in the context of model-to-text transformations enables the reuse and customization that Software Product Lines promote.
Related Work Merging MDD and product lines is not new, we know of examples that explicitly use features in MDD [9,8,10,11,12,22]. One is BoldStroke: a product-line for supporting a family of mission computing avionics for military aircraft [12]. Czarnecki introduces super-imposed variants and model templates to map features to models [8]. Weber et al. introduce the Variation Point Model that models variation points at the design level [26]. There is a line of work on feature-based composition of models. Featureoriented model-driven development is an approach that ties feature composition to model driven development [25]. Recent work by Apel describes superimposition as a model composition technique to support variability of product lines [2]. FeatureMapper is a tool that supports mapping features from feature models to solution artifacts [13]. These works do not yet consider the composition of model transformations or metamodels. Sanchez-Cuadrado presents an approach for the reuse of model transformations in RubyTL by using an idea reminiscent of libraries in programming [6]. This rst step towards model transformation reuse does not yet incorporate the notion of product family. The superimposed modules of ATL language can be composed into dierent transformation de nitions. This is not related to features, neither to the notion of composition demanded in a product family scenario [15]. Oldevik proposes an aspect-based extension of the MOFScript model-totext transformation language, which is called a Higher Order Transformations (HOT) [18].
Conclusions This paper presented an approach for the variability of MOFScript-based modelto-text transformations in a software product line scenario. The main contribution is the application of step-wise-re nement in the context of a model transformation. Doing so, the application of variability shifts from scenarios focused only on model variability towards broader scenarios handling the variability of MDD-related artifacts. We claim the need to shift our research attention from the variability of models to a broader perspective embracing the variability of models, metamodels and model transformations. This is indeed the direction of our current research eorts where we are addressing the variability of models, metamodels, and model transformations and their relationships concomitantly, since we believe they are often closely inter-related.
Acknowledgments.
This work was co-supported by the Spanish Ministry
of Science & Innovation under contract TIN2008-06507-C02-02. We thank to Maider Azanza for her comments on earlier drafts.
References 1. F. I. Anfurrutia, O. Díaz, and S. Trujillo. On Re ning XML Artifacts. In ICWE, pages 473478, 2007. 2. S. Apel, F. Janda, S. Trujillo, and C. Kaestner. Model Superimposition in Software Product Lines. In 2nd International Conference on Model Transformations (ICMT 2009), Zurich, Switzerland, June, 2009. 3. D. Batory, J.Neal Sarvela, and A. Rauschmayer. Scaling Step-Wise Re nement. IEEE Transactions on Software Engineering (TSE), 30(6):355371, June 2004. 4. J. Bézivin, G. Dupe, F. Jouault, G. Pitette, and J. E. Rougui. First Experiments with the ATL Model Transformation Language: Transforming XSLT into XQuery. In 2nd OOPSLA Workshop on Generative Techniques in the context of MDA, Anaheim, California, USA, Oct 27, 2003. 5. P. Clements and L.M. Northrop. Software Product Lines - Practices and Patterns. Addison-Wesley, 2001. 6. J. Sanchez Cuadrado and J. Garcia Molina. Approaches for Model Transformation Reuse: Factorization and Composition. In International Conference of Model Transformations (ICMT), 2008. 7. J. Sánchez Cuadrado, J. García Molina, and M. Menárguez Tortosa. RubyTL: A Practical, Extensible Transformation Language. In 2nd European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA 2006), Bilbao, Spain, Jul 10-13, pages 158172, 2006. 8. K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template Approach Based on Superimposed Variants. In 4th International Conference on Generative Programming and Component Engineering (GPCE 2005), Tallinn, Estonia, Sep 29 - Oct 1, 2005. 9. K. Czarnecki and M. Antkiewicz. Model-Driven Software Product-Lines. In
20th
Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,
,
Languages, and Applications (OOPSLA 2005), San Diego, CA, USA, Oct 16-20
2005.
10. S. Deelstra, M. Sinnema, J. van Gurp, and J. Bosch. Model Driven Architecture as Approach to Manage Variability in Software Product Families. In Workshop on Model Driven Architecture: Foundations and Applications (MDAFA), Enschede, The Netherlands, June 26-27, 2003. 11. B. Gonzalez-Baixauli, M.A. Laguna, and Y. Crespo. Product Lines, Features, and MDD. In 1st Europeean Workshop on Model Transformation (SPLC-EWMT'05), Rennes, France, Sep 25, 2005. 12. J. Gray and et al. Model Driven Program Transformation of a Large Avionics Framework. In 3th International Conference on Generative Programming and Component Engineering (GPCE 2004), Vancouver, Canada, Oct 24-28, 2004. 13. F. Heidenreich, J. Kopcsek, and C. Wende. FeatureMapper: Mapping Features to Models. In 30th International Conference on Software Engineering (ICSE 2008), Companion, pages 943944, New York, NY, USA, may 2008. ACM. 14. D. Herst and E. Roman. Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) - Approach: A Productivity Analysis. Technical report, TMC Research Report, 2003. 15. F. Jouault and I. Kurtev. Transforming Models with the ATL. In International Conference on Model Driven Engineering Languages and Systems (MODELS 2005), 2005. 16. K. C. Kang and et al. Feature Oriented Domain Analysis Feasability Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, November 1990. 17. I. Kurtev. Adaptability of Model Transformations. PhD thesis, University of Twente, 2005. 18. J. Oldevik and O. Haugen. Higher-order transformations for product lines. Software Product Line Conference, International, 0:243254, 2007. 19. OMG. MDA Success Stories. http://www.omg.org/mda/products_success.htm. 20. OMG. MDA Guide version 1.0.1. OMG document 2003-06-01, 2003. 21. K. Pohl, G. Bockle, and F. van der Linden. Software Product Line Engineering Foundations, Principles and Techniques. Springer, 2006. 22. D. Schmidt, A. Nechypurenko, and E. Wuchner. MDD for Software Product-Lines: Fact or Fiction. In Workshop at 8th International Conference on Model Driven Engineering Languages and Systems (MoDELS 2005), Montego Bay, Jamaica, Oct 2-7, 2005, 2005. 23. S. Sendall and W. Kozaczynski. Model Transformation: The Heart and Soul of Model-Driven Software Development. IEEE Software, 20(5):4245, 2003. 24. A. Sánchez-Barbudo, E. V. Sánchez, V. Roldán, A. Estévez, and J.L. Roda. Providing an Open Virtual-Machine-based QVT Implementation. In Proceedings of the V Workshop on Model-Driven Software Development. MDA and Applications (DSDM'08 - XIII JISBD), 2008. 25. S. Trujillo, D. Batory, and O. Díaz. Feature Oriented Model Driven Development: A Case Study for Portlets. In 29th International Conference on Software Engineering (ICSE 2007), Minneapolis, MN, USA, May, 2007. 26. D.L. Webber and H. Gomaa. Modeling Variability in Software Product Lines with the Variation Point Model. Science of Computer Programming, 53, 2004.
IKERLAN Research Centre, Spain {strujillo, ander.zubizarreta, jdesosa, xmendialdua}@ikerlan.es
Abstract. Model Driven Development (MDD) is a paradigm to automate the generation of code. A key artifact in this paradigm is a model transformation which de nes the mappings from a model to another model or even a code artifact. Although MDD was initially aimed at the generation of an individual program, shortly after appeared the need for families of programs. Hence, the combination of Model Driven and Software Product Lines (SPL) appears as a promising paradigm. Most of the previous work was focused on the necessity to support variability on models, but little work has been done so far on supporting the variability of remaining MDD artifacts such as model transformations or metamodels. This work rst motivates the need for variability of model transformations. We address then the application of step-wise re nement to model-to-text transformations expressed in MOFScript. We illustrate this with a case study.
Introduction Modeling is essential to cope with the increasing complexity of current software systems. Models assist developers during the entire development life cycle to precisely capture and represent relevant aspects of a system from a given perspective and at an appropriate level of abstraction. MDD is a paradigm to automate the generation of boiler-plate code. Raising the abstraction level enables to focus on the domain details and separate the implementation details. This brings a number of speci c bene ts such as productivity, reduced cost, portability, drops in time-to-market, and improved quality. Overall, the main economic driver is the productivity gain achieved, which is reported by some studies [14,19]. A key artifact in MDD is a model transformation that de nes the mappings between a model and another model or between a model and a code artifact. Although MDD was initially aimed at the generation of an individual program, shortly after appeared the need for families of programs. Researchers and practitioners have realized the necessity for modeling variability of software systems, where software product line engineering poses major challenges [25]. A software product line is a set of software intensive systems that are tailored to a speci c domain or market segment and that share a common set of features [5,21].
For example, in industrial software systems the presence of dierent types of subsystems (e.g., exclusive subsystems from dierent providers) implies that each is controlled in a similar though dierent way. This is typically achieved by de ning two features that are not necessarily present in all possible systems. A feature is an end-user visible behavior of a software system, and features are used to distinguish dierent software systems or variants of a software product line [16]. This impacts not only on the implementation, but on the modeling level. The modeling used in software product lines can be twofold. First, there are approaches for describing the variability of a software product line, e.g, there are feature models that specify which feature combinations produce valid variants [16]. Second, all variants in the product line may have models that describe their structure, behavior, etc. However, when dealing with variability in an MDD scenario, there are further artifacts apart from models that may need to cope with such variability. Model transformations are a case in point. In some scenarios, they may have too to cope with the variability imposed by the software product line. Hence, this paper takes a step back to study such impact into a broader perspective by analyzing the scenarios for Model Driven Product Lines. We shift our attention from the variability of models to a more general situation where the variability may embrace models, metamodels and model transformations. Hence, a realization of one feature may consist of variations of such artifacts. This work speci cally analyzes the variability of model transformations. The contribution of this paper is to apply step-wise re nement to model transformations. MOFScript-based model-to-text transformations are re ned by using XAK [1]. We illustrate our ideas with a simplistic case study, which is inspired on the industrial cases we work with. We begin by reviewing the background.
Background
Model Driven Development
is a paradigm where models are used to develop
software. This process is driven by model speci cations and by transformations among models or models and code. It is the ability to transform among dierent model representations that dierentiates the use of models for sketching out a design from a more extensive model-driven software engineering process where models yield implementation artifacts. This paradigm eases cumbersome and repetitive tasks, and achieves productivity gains. The main artifacts in MDD are models, metamodels and model transformations.
Models. Model is a term widely used in several elds with slightly dierent
meanings. A model represents a part of the reality called the object system and is expressed in a modeling language. A model provides knowledge for a certain purpose that can be interpreted in terms of the object system [17]. Typical
Fig. 1.
A simpli ed statechart for a temperature sensor
examples of models involve statecharts that represents the behavior of some functionality or class diagrams that show the structure of some code. Figure 1 shows a simple statechart model showing the behavior of a simple temperature sensor. The statechart has states
sClosed and sOpened in addition
to initial and nal states. Transitions between states and the conditions for these transitions are described in the model. The actions to be executed should be de ned too, but are omitted in the example.
Metamodels. A model is frequently considered an instance conforming to a
metamodel. A metamodel is a model of a modeling language where the language is speci ed [17]. In other words, the metamodel describes the elements of the domain and their relationships. A metamodel for a statechart might de ne its elements such as states, transitions, their relationships, etc. Note that the model in Figure 1 might conform to such metamodel. The mappings between metamodels are typically de ned by model transformations.
Model Transformations.
Model transformations play a pivotal role in
MDD because they turn the use of models for sketching into a more extensive model-driven usage where implementations can be directly obtained [23]. A model transformation is the process of converting one model to another model of the same system [20]. In general, a model transformation is the process of automatic generation from a source model to a target model, according to a transformation de nition, which is expressed in a model transformation language [17]. Depending on the target, model transformations can be model-to-model or model-to-text transformations. The former takes as input one or more models conforming to given metamodels and produces one or more models conforming to the same or another metamodels. The latter produces text as its output, that can be implementation code, documentation, or any other textual form. Model-to-model transformations usually make use of rules that are de ned as mappings between input and output metamodels. Model-to-text transformations combine rules with text templates that de ne the form of the output text.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
t e x t t r a n s f o r m a t i o n b a s e T r a n s f ( i n s c : " h t t p : / /www. w3 . o r g /2005/07/ scxml " ) { var o u t p u t F i l e : S t r i n g s c . ScxmlType : : main ( ) { f i l e ( outputFile ) writeSwitchStart () s e l f . s t a t e −>f o r E a c h ( s : s c . StateType ) { s . generateSwitchCases () } writeDefault () writeSwitchEnd ( ) } module : : w r i t e S w i t c h S t a r t ( ) { / ∗ Empty r u l e : t o be r e f i n e d l a t e r on ∗ / } }
/ ∗ Content o m i t t e d ∗ /
Fig. 2.
Example of a model-to-text transformation using MOFScript
There is a variety of open-source and commercial tools and languages for model
1
transformations . Our case study focuses on model-to-text transformations de ned using MOFScript transformation language. MOFScript language is a metamodel-independent language that allows to use any kind of metamodel and its instances for text generation. MOFScript tool is based on EMF and it is available as an Eclipse plugin. The de nition of a MOFScript transformation consists of rules. Figure 2 shows a base transformation de nition for transforming a statechart model into textual code. Implementation-wise, a transformation module called
baseTransf
is de ned. Such module is composed by several rules. They can have a context
2
type scoping to which metamodel elements can be applied such rules .
On the Need for Variability A Model Driven Development scenario typically involves models, metamodels and model transformations. Next, we analyze the need for variability of model transformations.
1
2
ATL [4], RubyTL [7], ATC [24] and other tools are for model transformations. Though these tools may be also used (and so we do) for model-to-text transformations, we focus on MOFScript since it is specialized on model-to-text. The execution of the transformation in Figure 2a starts with the sc.ScxmlType::main() rule. This rule is applied to the context type scoped by the type ScxmlType where sc is the input model. That means that it applies to every ScxmlType in sc. The output text le is de ned with file().
Scenario.
There are dierent scenarios when combining MDD and SPL.
Consider the dierences on the modeling language used: it is not the same to use UML or a Domain Speci c Language (DSL). There are scenarios where model variability may be enough and the variability of model transformations may not be needed. This may happen in situations where the used metamodel is standard and so it is not subject to variability. For instance, when using a UML class diagram, it seems unlikely to make its metamodel variable since it is somehow standardized. This may apply generally to the metamodels within the UML. A similar situation occurs when the model transformations come from a common library of model transformations that are shared. For instance, consider the dozens of model transformations expressed in
3
ATL that are available online . Therefore, in scenarios with standard metamodels and/or shared transformations, the use of model variability seems enough and thus variability of model transformations may not be needed. However, there exist other scenarios where the variability of model transformations may be needed. Consider the case in which dierent models and model transformations may need to be customized for dierent targets. Model transformations share a significant common part while diering in some variable parts. For instance, dierent implementation code can be generated from the same source model. The target code is expected to be executed in dierent platforms with dierent programming languages. This situation could be well handled by de ning features of the software product line. There is a large proportion of shared code and some particularities are bound to each programming language. In such situation, the application of variability to model transformations may enable to handle those dierences in a unique model transformation. Next, we illustrate this with our case study.
Case Study.
Although this motivating scenario is realistically more likely
to occur within a larger system, we illustrate our ideas with a family of control software systems developed following MDD. Particularly, we focus on the control of a simple temperature sensor that opens/closes some device (e.g. water pump). Our motivating scenario demands to cope with the variability of models, metamodels and model transformations. The les used in this example are available
4
online . Consider a model of a simple state machine and a model-to-text transformation de nition to get implementation code from it. The aim is to generate a switch statement implementing the statechart model. There are however dierent target platforms for the generated code. Such dierent programming languages are Ada and Java. Switch statements dier from Ada to Java. Actually, Ada does not provide a proper switch statement, but a case statement with equivalent structure and behavior to Java's switch. It would be possible to de ne a separated and independent model transformation de nition for each target language. In that way, however, it would be
3 4
http://www.eclipse.org/m2m/atl/atlTransformations/ http://www.ikerlan.es/softwareproductline/jisbd2009examples.zip
necessary to de ne a new transformation de nition for each new target language we would like to generate code for. Doing so, no reuse will be achieved. The structure of the switch statement is similar in most of the programming languages. Its dierence mostly lies in the syntax. Hence, it would be possible to de ne a base transformation common for all target platforms and to re ne it with partial or re ned transformations incorporating target speci c elements. This is what we called in this work as the re nement of model-to-text transformations.
Re nement-based Variability The re nement of model-to-text transformations is introduced in order to enable their customization for dierent variability needs. In our example, there is a statechart as a source model, Ada and Java as target programming languages and a model-to-text transformation with variability incorporated to connect the source with dierent targets. As a case in point, we considered the generation of switch statements that implement the code of a statechart model. Although switch statements are commonly found in most of current programming languages, they are not exactly de ned in the same way. In our example, we de ne a base transformation with all the common elements of the switch, that will be re ned for each output language. There will be a transformation re nement associated to each target language, each adding its speci c elements.
Base of a Transformation 1 2 3 4 5 6 7 8 9 10 11
<MOFScriptModel:MOFScriptSpecification . . . x a k : a r t i f a c t=" b a s e . m2t . model . m o f s c r i p t " x a k : f e a t u r e=" baseTrans ">
Fig. 3.
Base Transformation (XMI representation)
A base transformation de nition has been de ned with MOFScript (see Figure 2). This de nition takes a statechart model as input, and has the rules to generate a switch statement as output. Since the switch statement diers among dierent languages, this base transformation only has the common elements.
In our example, the base transformation de nes some common rules to generate a switch statement based on the statechart model. Some rules for writing the output are de ned (e.g.
writeSwitchStart)
but they are empty due to the fact
that the output text varies depending on the syntax of the output programming language. In the base transformation a variable named
outputFile
is de ned
too, to specify the name of the output le, but this variable is not yet given a particular value. The assignment will be done with a re nement, which will assign a name related to its output language later on. MOFScript allows to represent a transformation de nition as a model, conforming to the MOFScript metamodel. Figure 3 shows the model representation of the transformation using XML Metadata Interchange (XMI). (Note that this gure is equivalent to the textual representation of the transformation in Figure 2.) The transformation module is de ned with the
element. Nested to this element, variables, parameters and rules are de ned using the
and
elements,
respectively. Actually, the base transformation can not be executed standalone since it is not complete, so it may not generate the expected implementation. The base transformation needs to be re ned for each output language.
Re nement of a Transformation
1 2 3 4 5 6 7 8 9 10 11 12 13 14
< x a k : r e f i n e s x a k : a r t i f a c t=" b a s e . m2t . model . m o f s c r i p t " x a k : f e a t u r e=" adaDelta " . . . > <x a k : e x t e n d s xak:module=" oFileModule "> <x a k : s u p e r xak:module=" oFileModule "/>
Fig. 4.
XAK-based Re nement of a Transformation
A re nement can be deemed of as a function that takes an artifact as an input, and returns another similar artifact which has been leveraged to support a given feature [3]. XAK is a language for de ning re nements in XML documents and provides a composer tool for them [1]. We used it for representing and composing our MOFScript-based transformations. MOFScript oers the option to represent
a transformation de nition as a model. Such model can be represented using XMI. Therefore, XAK can be used for re ning such transformations. Any traditional XML document can be a base document, but some addi-
@xak:artifact @xak:feature are added to the document root element. The rst one spec-
tional annotations are needed (see Figure 3). The attributes and
i es the name of the document that is being incrementally de ned, while the second one speci es the name of the feature being supported (base for base documents). To specify which elements are modularizables,
@xak:module is used.
That is, it indicates those elements that play the role of modules, and henceforth can be re ned. In general, a XAK module has a unique name. Re nement documents re ne base documents and they have
<xak:refines>
element as root (see Figure 4). Its content describes a set of module re nements
xak:module attribute) extending a given base xak:artifact attribute). The xak:super node is a marker
(i.e. elements annotated with the document (i.e. the
that indicates the place where the original module body is to be substituted. In general, a XAK re nement document can contain any number of
xak:module
re nements. Those elements of the transformation that can be re ned must be de ned before re ning such transformation. In our example, the re nement units are the transformation de nition itself, variables and rules. That is, we can add new rules or variables to the transformation de nition, we can add or set values to variables already de ned, or we can extend existing rules with new statements.
xak:module attribute to
We add and
3). Note that not all elements are modularizable, but only those we designate beforehand by
xak:module.
Figure 4 shows a re nement for the base transformation. This re nement re nes the base transformation de nition to generate the code in Ada programming language. Some of the rules in the base transformation are re ned adding Ada speci c elements. The variable
outputFile is given a value. The rules that 5
are re ned are those which are used to produce speci c code to the output le . Since the syntax diers between languages, those rules must be re ned for each language.
Composition of Base and Re nements XAK composer tool is used to compose the re nement to the base transformation, executing the following command:
> xak -xak2 -c baseTrans.mofscript adaDelta.xak -o composedAdaTrans.mofscript
5
Due to the lack of space, in the gure only the re nement of the rule writeSwitchStart is shown. The complete example is available for download at http://www.ikerlan.es/softwareproductline/jisbd2009examples.zip
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
<MOFScriptModel . . . >
1 2
/ ∗∗
3 4
∗/ texttransformation baseTransf ( i n s c : " h t t p : / /www. w3 . o r g /2005/07/ scxml " ) { var o u t p u t F i l e : S t r i n g = " example . adb " ;
5 6 7 8 9 10 11 12 13 14
∗ T r a n s f o r m a t i o n Generated by
MOFScript2Text transformation
/ ∗ Content o m i t t e d ∗ / module : : w r i t e S w i t c h S t a r t ( ) { " c a s e s t a t e i s \n " } / ∗ Content o m i t t e d ∗ / }
(a) Fig. 5.
tation
1 2 3 4 5 6 7 8 9 10 11
(b)
Composed Transformation: (a) XMI representation; (b) MOFScript represen-
case s t a t e i s when s C l o s e d => i f isWarm then
s t a t e := sOpened ; end i f ; when sOpened => i f i s C o o l then s t a t e := s C l o s e d ; end i f ; when others => end case ;
1 2 3 4 5 6 7 8 9 10 11 12 13
switch ( s t a t e ) { case s C l o s e d : i f ( isWarm ) { }
s t a t e = sOpened ;
break ; case sOpened : i f ( isCool ) { }
}
state = sClosed ;
break ; default :
(a)
(b) Fig. 6.
Generated code: (a) Ada; (b) Java
The result of the composition is a composed transformation model (Figure 5a), which can be executed directly giving as input the statechart model, or can be converted to a MOFScript transformation de nition le (Figure 5b) using that option in MOFScript tool and then executed. Note that some rules that were empty in the base transformation de nition, have now some body specifying how the output has to be in Ada programming language. So, the customization of model transformations is achieved. The output of the transformation is the
example.adb le which has the switch statement according to our model, written in Ada syntax (Figure 6a). Another possible re nement may be to re ne the base transformation de nition to generate Java code. In this case, the rules should be re ned to generate Java code. Although the structure of the generated code is almost the same, the syntax diers from Ada to Java. Additionally,
break; sentences are necessary in
Java, so a new rule needs to be added to the base transformation to write such sentences. The new rule will be called from
generateSwitchCases
rule, that
need to be re ned to add the new statement. Figure 6b shows the code obtained when running the transformation re ned for Java. The use of re nements in the context of model-to-text transformations enables the reuse and customization that Software Product Lines promote.
Related Work Merging MDD and product lines is not new, we know of examples that explicitly use features in MDD [9,8,10,11,12,22]. One is BoldStroke: a product-line for supporting a family of mission computing avionics for military aircraft [12]. Czarnecki introduces super-imposed variants and model templates to map features to models [8]. Weber et al. introduce the Variation Point Model that models variation points at the design level [26]. There is a line of work on feature-based composition of models. Featureoriented model-driven development is an approach that ties feature composition to model driven development [25]. Recent work by Apel describes superimposition as a model composition technique to support variability of product lines [2]. FeatureMapper is a tool that supports mapping features from feature models to solution artifacts [13]. These works do not yet consider the composition of model transformations or metamodels. Sanchez-Cuadrado presents an approach for the reuse of model transformations in RubyTL by using an idea reminiscent of libraries in programming [6]. This rst step towards model transformation reuse does not yet incorporate the notion of product family. The superimposed modules of ATL language can be composed into dierent transformation de nitions. This is not related to features, neither to the notion of composition demanded in a product family scenario [15]. Oldevik proposes an aspect-based extension of the MOFScript model-totext transformation language, which is called a Higher Order Transformations (HOT) [18].
Conclusions This paper presented an approach for the variability of MOFScript-based modelto-text transformations in a software product line scenario. The main contribution is the application of step-wise-re nement in the context of a model transformation. Doing so, the application of variability shifts from scenarios focused only on model variability towards broader scenarios handling the variability of MDD-related artifacts. We claim the need to shift our research attention from the variability of models to a broader perspective embracing the variability of models, metamodels and model transformations. This is indeed the direction of our current research eorts where we are addressing the variability of models, metamodels, and model transformations and their relationships concomitantly, since we believe they are often closely inter-related.
Acknowledgments.
This work was co-supported by the Spanish Ministry
of Science & Innovation under contract TIN2008-06507-C02-02. We thank to Maider Azanza for her comments on earlier drafts.
References 1. F. I. Anfurrutia, O. Díaz, and S. Trujillo. On Re ning XML Artifacts. In ICWE, pages 473478, 2007. 2. S. Apel, F. Janda, S. Trujillo, and C. Kaestner. Model Superimposition in Software Product Lines. In 2nd International Conference on Model Transformations (ICMT 2009), Zurich, Switzerland, June, 2009. 3. D. Batory, J.Neal Sarvela, and A. Rauschmayer. Scaling Step-Wise Re nement. IEEE Transactions on Software Engineering (TSE), 30(6):355371, June 2004. 4. J. Bézivin, G. Dupe, F. Jouault, G. Pitette, and J. E. Rougui. First Experiments with the ATL Model Transformation Language: Transforming XSLT into XQuery. In 2nd OOPSLA Workshop on Generative Techniques in the context of MDA, Anaheim, California, USA, Oct 27, 2003. 5. P. Clements and L.M. Northrop. Software Product Lines - Practices and Patterns. Addison-Wesley, 2001. 6. J. Sanchez Cuadrado and J. Garcia Molina. Approaches for Model Transformation Reuse: Factorization and Composition. In International Conference of Model Transformations (ICMT), 2008. 7. J. Sánchez Cuadrado, J. García Molina, and M. Menárguez Tortosa. RubyTL: A Practical, Extensible Transformation Language. In 2nd European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA 2006), Bilbao, Spain, Jul 10-13, pages 158172, 2006. 8. K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template Approach Based on Superimposed Variants. In 4th International Conference on Generative Programming and Component Engineering (GPCE 2005), Tallinn, Estonia, Sep 29 - Oct 1, 2005. 9. K. Czarnecki and M. Antkiewicz. Model-Driven Software Product-Lines. In
20th
Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,
,
Languages, and Applications (OOPSLA 2005), San Diego, CA, USA, Oct 16-20
2005.
10. S. Deelstra, M. Sinnema, J. van Gurp, and J. Bosch. Model Driven Architecture as Approach to Manage Variability in Software Product Families. In Workshop on Model Driven Architecture: Foundations and Applications (MDAFA), Enschede, The Netherlands, June 26-27, 2003. 11. B. Gonzalez-Baixauli, M.A. Laguna, and Y. Crespo. Product Lines, Features, and MDD. In 1st Europeean Workshop on Model Transformation (SPLC-EWMT'05), Rennes, France, Sep 25, 2005. 12. J. Gray and et al. Model Driven Program Transformation of a Large Avionics Framework. In 3th International Conference on Generative Programming and Component Engineering (GPCE 2004), Vancouver, Canada, Oct 24-28, 2004. 13. F. Heidenreich, J. Kopcsek, and C. Wende. FeatureMapper: Mapping Features to Models. In 30th International Conference on Software Engineering (ICSE 2008), Companion, pages 943944, New York, NY, USA, may 2008. ACM. 14. D. Herst and E. Roman. Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) - Approach: A Productivity Analysis. Technical report, TMC Research Report, 2003. 15. F. Jouault and I. Kurtev. Transforming Models with the ATL. In International Conference on Model Driven Engineering Languages and Systems (MODELS 2005), 2005. 16. K. C. Kang and et al. Feature Oriented Domain Analysis Feasability Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, November 1990. 17. I. Kurtev. Adaptability of Model Transformations. PhD thesis, University of Twente, 2005. 18. J. Oldevik and O. Haugen. Higher-order transformations for product lines. Software Product Line Conference, International, 0:243254, 2007. 19. OMG. MDA Success Stories. http://www.omg.org/mda/products_success.htm. 20. OMG. MDA Guide version 1.0.1. OMG document 2003-06-01, 2003. 21. K. Pohl, G. Bockle, and F. van der Linden. Software Product Line Engineering Foundations, Principles and Techniques. Springer, 2006. 22. D. Schmidt, A. Nechypurenko, and E. Wuchner. MDD for Software Product-Lines: Fact or Fiction. In Workshop at 8th International Conference on Model Driven Engineering Languages and Systems (MoDELS 2005), Montego Bay, Jamaica, Oct 2-7, 2005, 2005. 23. S. Sendall and W. Kozaczynski. Model Transformation: The Heart and Soul of Model-Driven Software Development. IEEE Software, 20(5):4245, 2003. 24. A. Sánchez-Barbudo, E. V. Sánchez, V. Roldán, A. Estévez, and J.L. Roda. Providing an Open Virtual-Machine-based QVT Implementation. In Proceedings of the V Workshop on Model-Driven Software Development. MDA and Applications (DSDM'08 - XIII JISBD), 2008. 25. S. Trujillo, D. Batory, and O. Díaz. Feature Oriented Model Driven Development: A Case Study for Portlets. In 29th International Conference on Software Engineering (ICSE 2007), Minneapolis, MN, USA, May, 2007. 26. D.L. Webber and H. Gomaa. Modeling Variability in Software Product Lines with the Variation Point Model. Science of Computer Programming, 53, 2004.
Related Documents
Refinement Of Talents
November 2019 4
Transformations
May 2020 17
Transformations
May 2020 16
Linear Transformations On Hilbert Spaces
November 2019 10More Documents from "hyd arnes"
20090225_mofscript_xak
May 2020 13
Is Model Variability Enough?
May 2020 4
20090129 Presentacion Area
May 2020 11