Generative Adaptation of Model Transformation Assets Experiences, Lessons and Drawbacks Fábio Paulo Basso, Raquel Mainardi Pillat, Toacy Cavalcante Oliveira Universidade Federal do Rio de Janeiro (UFRJ) COPPE - Rio de Janeiro - RJ, Brazil
Marcos Didonet Del Fabro Universidade Federal do Paraná (UFPR), C3SL Curitiba - PR, Brazil
[email protected]
{fabiopbasso, rmpillat, toacy}@cos.ufrj.br
ABSTRACT Model transformation is a central activity in Model Driven Engineering (MDE) as it specifies how models are consumed to generate other models or code. Complex scenarios typically involve the execution of several transformations that, due to variability of solutions to develop software projects, need to be tailored to attempt different implementation technologies, libraries, patterns, etc. Recent proposals to tailor these assets suggested that current Software Product Line (SPL) techniques can be used to promote reuse of model transformation assets. However, in a recent case study, we have found lacks in techniques, including ours, to apply reuse for this domain in particular. Thus, this paper presents this case study and discusses implications and challenges in tailoring these assets with SPL techniques.
Categories and Subject Descriptors D.3.2 [Design]: Theory; D.2.8 [Software Engineering]: Design Tools and Techniques—Computer aided software engineering (CASE), Model driven development (MDD)
Keywords Transformation Chain; Transformation Process; Model Driven Engineering; Feature Model; Software Product Line.
1. INTRODUCTION Model Driven Engineering (MDE) [12] focuses on designing software models used to generate code or other models. In this scenario, generation occurs by means of Model Transformations (MTs) that are executed by MDE tools such as FeatureIDE [33] and Andromeda [4]. These tools must be tailored to apply transformations for specific software implementation details. With the increasing adoption of MDE techniques [22], it is becoming common for MDE practitioners specify model transformations for different software
Permission 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. SAC’14 March 24-28, 2014, Gyeongju, Korea. Copyright 2014 ACM 978-1-4503-2469-4/14/03 ...$15.00.
projects that require different framework versions, different libraries and also different implementation patterns [33]. In this context, software engineers must deal with communalities and variants of model transformation assets [36]. Assets are composed by model transformations, fragments of source-code of text-based (white box) transformations, modules of transformations used in black box programs (object files), transformation rules, MDE tool configuration files and chains of model transformations [27]. These assets can be specified with diverse languages, techniques and tools [12]. Aiming to promote the reuse of model transformation assets, some proposals focuses in how to ensure consistency in transformation compositions [38], while others focuses in high-level specification and management of transformation chain that can be further generated for specific MDE tool configurations [35]. Other proposals in [2, 3] applies reuse through generative techniques based on Software Product Line (SPL) [11]. These proposals are useful to adapt model transformations with different reuse techniques. Our proposal is to develop large scale model transformations managed as a SPL. In order to find characteristics that composes communalities and variabilities in model transformation assets, a designer perform a domain analysis [24]. Currently a widely used notation in domain analysis is the Feature Model (FM) [16]. The Feature Model is useful to define system characteristics (functional, architectural, technological, mixed, among other ones) from a particular implementation domain and to use features relationship to configure different target implementations in MDE [32]. In this sense, our work uses FM to tailor model transformation assets with some SPL-based reuse techniques. The application of SPL techniques in this context is not a novelty, since works [2, 3] have applied it to generate Model Transformation Chains (MTCs) and Volter et al. in [36] exemplified the use of dynamic reconfiguration of MTCs. However, literature lack in case studies on the application of such techniques for other reusable assets such as configuration files and, more important, transformation rules. In order to drive future researches, these experiences are important to understand challenges to adapt model transformation assets in real scenarios. In this direction, this paper presents a case study conducted in a real scenario and discusses positive results and drawbacks that are important to improve reuse techniques for this domain in particular. This paper is organized as follows. Section 2 summarizes
Figure 1: Exemplification of an application model.
basic concepts and a motivating scenario. The first part of the case study is presented in Section 3, with some examples of transformation assets designed with WCT. Section 4, in a second part of the case study, demonstrates how to tailor domain models to a specific MDE tool by generating a configured MTC. Related works are discussed in Section 5 and, in Section 6, conclusions remarks punctuate some observations, implications and challenges in tailoring these assets with SPL techniques.
2. MOTIVATING SCENARIO The development of information systems require the design and implementation of Graphic User Interface (GUI) as illustrated in Figure 1 (A). To allow the representation of details concerning information systems, e.g. actions performed by user on GUI elements (known as action semantics [25]), each GUI component can receive annotations that differentiate it from a common component such as illustrated with stereotypes and tags in Figure 1 (B). Besides provide information to generate source-code through transformations [17], annotations can be used to increment/enrich a preliminary GUI model. This is possible by transforming a GUI model to other ones (e.g. to generate a different GUI representation that allows one to generate source-code for a specific WEB user interface). The main reason to design this type of model is to reuse these specifications in software projects. However, one must consider that implementation technologies used to produce software evolves, meaning that the same model can be transformed to different target technologies used in legacy or in current software projects. This requires one to deal with different model transformations that generates code mapped for some technologies that in legacy systems are different than in current systems. For example, in order to generate source-code taking as input the model shown in Figure 1, three transformations from model-to-text (M2T) programmed with Velocity Templates [14] could be used as shown in Figure 2. Each transformation have communalities (fragments that should be reused) and differences (fragments that should be moved for a specific transformation). The example highlight in bold the differences between three technologies used to produce a View layer: JSP [10] is the acronym for Java Server Pages, a script language used to generate dynamic content for web pages, as shown in Figure 2 (A); JSTL and JSF have a similar goal and are exemplified
Figure 2: Variant Points for JSP, JSTL and JSF.
in Figure 2 (B) and (C). This type of variability is different than those related to application domains. These ones requires one to deal with variances in a single web-shop domain, such as the model shown in Figure 1, while the variants we are interested for are more like target platform features applicable for diverse application domains. In fact, implementation variabilities are cross-application domain and implies in manage communalities and differences in relation to model transformations assets, not to domain models. Software companies whose applications are derived from a base framework, that do not mutate, should not consider the techniques presented in this paper. However, for companies that need to tailors model transformations for different software projects (legacy and modern), managing implementation variability in code generators is crucial to core business. This would allow to generate new functionalities in increments for legacy systems [6], using model transformations for old-fashioned technologies, and developing new ones with modern technologies. With this in mind, our goal in next sections is to apply SPL techniques for model transformations assets. Moreover, one must focus in a cross-application domain variabilities, such as information systems domain, and not in application domain, such as the model illustrated in Figure 1. Therefore, we divided our study in two parts: the first one (Section 3) introduces concepts used to tailor transformation assets, while Section 4 presents the second part of the case study that focuses in application of SPL techniques to generate a MTC.
3.
CASE STUDY (PART I)
This case study uses a small part of what we did along five years in industry, whose technical architecture and model transformations are composed by variant technologies in support for Java platforms [34]. The study applies some reuse techniques in order to configure model transformation engines to support transformations for different software project
Figure 3: Platform Domain Model. configurations. Thus, it is partially based in a retrospective from past experiences [6, 7], but it present many novelties also in comparison to related works in [2, 3, 36].
3.1 Finding Cross-Domain Features In order to find communalities and differences in model transformation assets, first step is to execute a Domain Engineering process discussed in [24]. Variabilities are designed with help of a diagram shown in Figure 3. This model is called as Platform Domain Model (PDM) because it contains only features related to implementation details. Since our goal is to find features that are common for any application domain, must be avoided features about specific applications. With this in mind, one must avoid features related to the application model shown in Figure 1, because they constraint applicability of transformation for a single application domain, while our goal is to reuse model transformation assets in a cross-application domain. Thus, PDM must contain only non-functional features related to transformation assets such as: implementation techniques, implementation technologies, deployment platforms, etc. The PDM shown in Figure 3 exemplifies a domain model about information system application layers composed by implementation technologies: a) The Remote Layer feature is optional, but when selected one must decide to select between RMI, Http and Socket features, intended to provide the means to generate source-code for integration layer; b) The View Layer can be implemented for web and desktop and also mobile, but at least one of them must be selected; c) For Mobile one must decide between CDC or CLDC (used in Eclipse IDE) and for Web to decide between JSTL or JSF or JSP, both technologies available in Java to generate dynamic content. When Mobile is selected, then Remote Layer must be selected too, given the dependency stereotyped with «requires».
3.2 Representing Variability in a TCDM The design of PDM is assisted by a support tool WCT [9]. Once designed, features must be associated with model transformation assets. This way, does not make sense to use these techniques unless a large set of model transformations already exist or if one is intended to program transformations thinking in future reuse. Model transformation chains is one type of these assets that requires chaining transformations. Accordingly, WCT allows to design MTCs in a diagram called as a Transformation Chain Domain Model (TCDM). Moreover, it allows apply bindings between model transformations inputs and outputs (IO), illustrated in Figure 4 as dependencies (dotted arrows without stereotype).
A TCDM allows to orchestrate variant and mutually exclusive Model-to-Model (M2M), Model-to-Code (M2C) or Model-to-Text (M2T) transformations [17]. For example, the transformer number 3 in sequence is abstract (see Almeida et al. in [1] for more information about this concept) and is replaced in a transformation chain by one of their children: a) JSTL Transformer is used if the feature JSTL is selected in the PDM (see «requires» stereotyped dependencies); b) JSF Transformer is used if the feature JSF feature is selected. The mutually exclusion of these transformations is ensured by the XOR relationship owned by the Web feature and also by the abstract transformer. This example is different in the transformer number 2 because two transformers can be used in the same sequence: a) Mobile Transformer is used if the features Mobile and Remote Layer are selected in the PDM; b) Web Transformer is used if the Web feature is selected. The inclusive OR relationship owned by the View Layer feature ensure that at least one of these transformations is used, but it is possible to use both. Transformers illustrated in Figure 4 allow to generate models and code taking as input the model shown in Figure 1. They are organized chained as follows: 1- Generate Mockup, 2 - Mockup to Concrete UI, and 3 - Generate Web View code. Transformations are composed by parameters (input, output, specialization points, etc), dependencies and pre conditions. Parameters may have dependence links such as between the parameter named sa:ScreenArea to the transformer number 1 and also be classified as metamodels or data objects (default). Moreover, MTs may have other kinds of dependencies stereotyped with «requires» or «excludes», as shown in Figure 4 in transformers Web Transformer, JSTL Transformer and JSF Transformer. In pre-conditions, a target of a dependence is always a feature available in the PDM. A dependence relationship define when a model transformer must be used in a transformation chain sequence. In this sense, the Web Transformer will be used only if the feature Web is selected. As one may notice, our transformation chain modeled in Figure 4 does not require an IF clause to determine when a model transformer is used. Therefore, dependencies between features and transformers are responsible to apply this binding.
4.
CASE STUDY (PART II)
This Section shows the second part of the case study towards a generation of a transformation assets using as input the domain models exemplified in Section 3. This is executed in an instantiation process [24] where the PDM features are selected and, as sequence, transformation assets are adapted.
4.1
Adapting Text-based Assets
Any textual based transformation asset can be fragmented for specific features and then be merged considering the selected features in PDM [2]. In this sense, Figure 2 highlighted, in bold, differences between three text-based model transformations used to produce the View Layer for web applications: JSP, JSTL and JSF. Each one is represented as specific transformers placed into the transformation chain named Generate Web View Code TC as shown in Figure 5 (B) and the generic algorithm (transformation rule) owned by the transformer Generate Web View code is shown in Figure 5 (A). Thus, after identify differences, it is neces-
Figure 6: Andromeda Transformation Chain.
Figure 7: Model Transformer Source-Code. Figure 4: Transformation Chain Domain Model.
sary to fragment model transformations with Specialization Points (SPs), also called in literature as variability points [20] and hotspots [29]. A Specialization Point is used to cut text fragments into specialized units. Further, these units are combined and compose a main model transformer considering their owned pre-condition rules in relationship with features. Figure 5 exemplifies these points applied over the generic model transformation named Generate Web View code in which content is clipped into transformation units shown in middle and right-part of the Figure 5 (B). Each unit provides text fragments constrained for each web view technology modeled in the PDM.
4.2 Model Transformation Chain Figure 6 illustrates a transformation chain used by Andromeda tool [21]. This tool is largely used in MDE projects to execute transformations, such as in MDArte framework [28] used by Brazilian government institutions. It contains a lot of configuration files that demonstrate applicability of SPL-based techniques in generating transformation assets. In this example, model transformers are programmed as XSL templates (lines 5 and 8), but they also could be expressed as ATL [23], Velocity Templates, Java binaries (compiled classes), etc. In order to generate a MTC taking as input the TCDM, the bold content shown in Figure 6 must be changed. The highlighted content must be replaced by those sequences of model transformers shown in Figure 4. Besides, because transformation rules were split into several fragments mapped for specific technologies shown in Figure 3, they must now be merged and packaged together with the generation of a MTC. Figure 7 illustrates part of source-code, developed with Velocity templates, required to generate a concrete transformation chain used in Andromeda. The velocity requires input parameters to apply a model-to-text (M2T) transformation. As we aim to transform the TCDM into a content used by Andromeda configuration file, we must set the diagram as the velocity input parameter. Thus, the input for this transformation is an instance of the metaclass TransformationDiagram that, due to reasons to save space,
is part of a metamodel not discussed in this paper. The diagram is placed as a velocity parameter in the line 11 as a parameter named transDiagram. The algorithm shown in Figure 7 checks if the diagram contains valid sequences (line 2-3) and then iterates over each concrete model transformer specified at the diagram (line 4). The operation called in line 2, named getConcreteTransformationSequences, verifies the pre-conditions owned by each model transformer to include it or not into the returned list. This means that it is responsible to verify which model transformers match a PDM selection, to include them into an ordered list used to generate the transformation chain. The rest of lines generates the content shown in Figure 6, using following model transformer properties: the name (line 5); the output (line 8) the transformation file (line 9).
4.3 Generating Configuration Properties In order to configure other required details by Andromeda, it is also necessary to generate file content shown in Figure 8 (A). This requires modifications into the model transformer that tailors Andromeda tool, as shown in Figure 8 B and C. In this case, one must deals with configuration properties: important details to configure Andromeda with a set of required libraries, application layers and other relevant information used to generate source-code for information system applications. In this sense, notice that the properties in lines 4 and 5, shown in Figure 8 (A): they can be mapped to the Struts feature shown in Figure 3 using UML tagged values and stereotypes. This is possible because TCDM and PDM metaclasses inherit from the UML superstructure. Therefore, one can add any extension representation into the designed elements, differently than other solutions restricted to expressing only information allowed by the MTC metamodel. In this sense, stereotypes and tags can be used to specify properties required by some MDE tool. For example: by annotating a feature from the PDM with stereotype «Namespace», one grant that it will be used as a namespace when tailoring Andromeda with transformations; besides, this information is used to generate the bold lines shown in Figure 8 (A). To adapt the example show in Figure 7, a modification
Figure 5: Fragmenting Transformation Rules in Variant Units. in the model transformer shown in Figure 8 (B) is required: to add an input parameter (between lines 3 and 6). This parameter is a list of features coming from the PDM that are used on the white box transformer shown in Figure 8 (B) to generate those properties on Figure 8 (A). Thus, this transformation generates the namespace tags into XML content by iterating over a list of features and checking those selected and with Namespace, merging the namespace tag with main transformation chain content. Finally, the return of the model-to-text transformation may be saved in a specific file representing the Andromeda’s transformation chain.
4.4 Final Steps In this stage it is required to tailor domain models for a target application (in our case, for Andromeda tool). Taking as input assets exemplified previously, model transformation assets are generated to attempt to a specific software project (target platform). Accordingly, Andromeda MTC is generated with the exemplified set of model transformations, using a M2T generation from TCDM to a MTC-based text specification shown in Figure 6. This way, the feature selection process (the PDM instantiation) is started and M2T transformations are executed. The instantiation process also merges model transformer fragments exemplified in Figure 5. It generates MT assets that are complete to support executions. Then, transformation assets are packed and Andromeda tool is configured to support a tailored transformation assets. Therefore, the result is a set of adapted transformation assets that run in a specific model transformation engine.
4.5 Lessons Learned Our experiences reinforce that SPL-based techniques are important to reuse model transformation assets, as suggested Volter et al. in [36], Asztalos et al. in [3] and Aranega et al. in [2]. This allows to adapt transformation assets to different software project needs, considering legacy systems and modern ones. However, it is important to notice that some benefits and drawbacks relies in each SPL-based technique regarding generative or runtime (also known as dynamic SPLs). They must be carefully considered when maintaining reusable model transformation assets. We have been using runtime and generative techniques
Figure 8: Generating Constrained Tags.
since 2006 [6, 7] and have learned that it is preferable to use runtime compositions for assets of type MTCs and model transformations. This is because they simplify adaptation, since runtime-based executions does not required a generation of MTCs, while a generative technique generates a new unit that requires to repeat tests for each new generated MTC. Moreover, as reported in [9], transformation fragments are mostly compiled Java programs, not textual fragments. This allows to use a previously validated component, not requiring retesting as it is necessary in generative adaptations of transformation assets. However, drawbacks of runtime SPL techniques are: 1) runtime-based techniques are strictly applicable for the WCT transformation execution engine and; 2) compiled fragments can be achieved only with Java programs because other transformation languages such as ATL or QVT do not support runtime-based SPL techniques discussed in this paper. Moreover, we have experienced that due to new requirements for specific implementation technologies, inevitable non-planned changes will be necessary in existing transformations, requiring refactoring of transformation assets (specially for model transformers). Refactoring requires a tiring procedure to test previous solutions (legacy model trans-
formers that now were modified ). In this regard, in [5] we reported about an industrial case study that required modification in some existing model transformations while software development already have been started. It was necessary to change some transformations to fit to new variants of Ajax technology (rich web user interfaces). The target of techniques is a tailored model transformation, derived from a single Ajax technology (initially in Dojotoolkit) for Dojotoolkit or jQuery. In this regard, in order to reduce the number of tests cases and save time, we found that tests also should be oriented to features. Thus, this would facilitate executions of test cases for both generative and runtime techniques.
4.6 Limitations Our work did not consider a scenario where model transformations, application models and metamodels evolves together. Since fragments of model transformations must be evolved when metamodel evolves, this figures a lack in our proposal that did not considered automatic techniques for co-evolution. In order to automatically apply changes in these three transformation assets, Lopez-Herrejon et al. [27] proposed a reuse technique for co-evolution. Corrˆea et al. in [15] highlighted some co-evolution tasks that can be automatically and also must be manually applied in models, metamodels and Graph-based transformations. Although they provide interesting perspectives in this direction, we find that due to a necessity to break transformations in fragments hampers the application of current co-evolution proposals. This work is focused in applying generative-based techniques and not depicted runtime-based techniques in support for model transformation reuse. However, runtimebased compositions for PLA are discussed in details in [6, 7, 31, 36]. Another limitation in this study is that we have used generative-based techniques applied in model transformation developed only with Velocity templates. In this sense, we are exploring other languages.
4.7 Considerations Some threats to validity constraints our findings and lessons we have learned in this case study. Internal Validity: The first part of this study was conducted in an industrial environment by using a developer that has Senior knowledge about Java J2EE Architecture. Moreover, this professional worked in many other software companies who used different frameworks and APIs to produce information systems. In this sense, this study is valid only for information systems development with Java target platform. External Validity: The results reported in this study can be generalized for others SPL-based techniques. Although domain models (PDM and TCDM) are designed with a particular tool named WCT, they can also be designed with other set of tool support discussed in Section 5. Moreover, SPL-based techniques can be applied in any text-based transformation asset. However, check of consistency in transformation compositions must not be considered, since the techniques presented in this paper are not directed to this goal. Reliability: This work is trustable guarded boundary conditions that the study presented: management of model
transformation assets, considering communalities and variabilities in information system development with variant Java J2EE architectures. In other words, this work is invalid in software development scenarios whose target architecture not varies.
5.
RELATED WORKS
The combination of FM and MTs was suggested by Tekinerdogan et al. in [32] and inspired our work. However, so far we have not identified any other approach that uses feature model to generate transformation assets such as ours do, considering a merge of a TCDM and a PDM in the same design. In this regard, since our study is based on SPL techniques, following related works can be mentioned: Kang et al. [24], Fernandes et al. [20], Benavides et al.[11] and Volter et al. [37]. They have not tackled adaptations on model transformation assets, but provided theory to apply the case study. In regard to variability in model transformations, as far as we know it, in [6, 7] we provided a first methodology an tool support to deal with variants in MTs. Volter et al. in [36] has a similar proposal. These works execute dynamic transformation chains ruled by a feature model. However, variants are specified directly into the MTC, a solution dependent from a model transformation execution engine. On the other hand, our solution allows specifying a model named TCDM that is used to generate MTCs used by any transformation execution engine. Recently, Aranega et al. in [2] applied existing SPL-based techniques to generate MTCs. However they also have not considered a MTC domain model as we demonstrated in a TCDM. In other words, they do not design MTCs, but they do design a PDM. As consequence, given that features are directly mapped for a MTC, Aranega et al. proposal is limited since a PDM must be defined for each transformation execution engine. In our proposal a TCDM is used as input for model transformations that allow to generate any text-based asset (MTCs, configuration files, model transformations with merged fragments and rules, and so on), independently from a transformation execution engine that will make use of them. Moreover, other approaches also generate MTCs, but they did not considered variants. In [32, 35, 1] it is discussed about importance of a language to connect transformations to target platforms. As a complement, Etien et al. in [19, 18] had been applied heterogenous model transformations developed with different metamodels. Although these proposals are important to generate MTCs, we considered in this work a wider set of asset types, including fragmented transformation rules, configuration files and properties. These related works, being focused only in MTC generation are limited, since other assets must also be generated as exemplified in previous sections. In this sense, our proposal is to generate automatically a MTC using domain models that composes model transformation assets (not only model transformers) considering variability and communality. Moreover, differently than in [6, 7, 36] that deals with variants in runtime, our work allow generating diverse assets without requiring a specific model transformation engine. In Almeida et al. [1] was proposed a solution to define MT compositions whit consecutive model-to-model transformations. They defined transformations tiers as abstract platforms represented with extensions of MOF [25] pack-
ages using a lightweight MDA approach. Nevertheless, it is not possible to have a notion about the sequence, a detail that makes their solution difficult to design transformations sequences. Since existing SPL-based techniques consider only variabilities and sequence is important to generate valid MTCs, their proposal is complementary for our work. As a new contribution, we propose to organize transformations in a domain of model transformation assets ruled by features of a platform domain. In Vanhooff et al. [35] target platforms are also used as a part of the MTCs. Target platform and MTs was composed using UML activity diagram, in a similar solution to our previous work [6], since our current solution is based on a DSM to draw MTCs. Some other approaches to support transformation orchestration are presented as graphical extensions from OMG’s UML [13] like Abstract Platforms [1] and MARTES UML Profile [35] and also not ensure consistency in transformation composition. In [38] proposed an approach to ensure consistency in composing MTCs. A lack in Yie’s approach is that they did not considered a composition between heterogeneous MTs, programmed with different supporting languages than ATL [23] and using different languages to specify MTCs as discussed in Asztalos et al. [3]. Similarly, this paper has the same lack, an ongoing work with some result presented in Pillat et al. [30].
6. CONCLUSIONS REMARKS This paper presented a case study on tailoring model transformation assets. In order to use SPL-based techniques for this domain in particular, it was introduced the design of a domain model composed by a Platform Domain Model (PDM) and a Transformation Chain Domain Model (TCDM). These models allows one to specify variabilities in model transformation chains as well as in other types of assets such as transformation rules, configuration files, and so on. This study allowed to configure assets for a specific transformation engine/tool named Andromeda. Finally, experiences and shortcomings were pointed, allowing to find drawbacks useful for further reuse researches. Considering a literature review and also current and previous experiences, we can highlight to some points that challenges the application of reuse techniques in order to adapt model transformation assets as follows. Co-evolution: Currently co-evolution proposals tackled by Lopez-Herrejon et al. [27] and Corrˆea et al. [15] did not considered a scenario where model transformations are fragmented. Thus, a specific solution for this reuse technique is necessary. Heterogeneity of model transformation languages: Co-evolution proposals were strictly applied for graph-based transformations. However, a TCDM can chain transformations programmed with ATL or specified in a graph-based language such as QVT and also data objects (Java data types). Yie et al. [38] and Guy et al. [21] presents some contributions, but considering only homogeneous compositions. Thus, another challenge is to validate transformation compositions in a TCDM considering a heterogeneity of solutions for specific transformation engines. Refactoring of model transformations: As mentioned in Section 4.5, refactoring of model transformations is inevitable since implementation technologies evolves. Thus, a challenge for the current reuse techniques is how-to reply modifications for fragmented units/rules when changes in
top-level units are necessary. Test-driven-development (TDD): TDD gained attention in industry. Current SPL techniques consider a set of existing similarities and differences in an existing set of assets. However, TDD consider the development of new model transformations. Accordingly, in [26] was suggested to develop model transformation chains with incremental steps, an ongoing work that we presented in [8] through automated test cases programmed with an extension for JUnit 4 API. Thus, an open question is how to apply these steps considering SPL-based techniques presented in this paper? Agile frameworks: Finally, TDD is a method recommend in agile frameworks such as Scrum. We can point to a central difference between agile and the presented procedure: while PDM and TCDM are designed in a top-down procedure, considering existing assets (first domain models than after development of MT), agile recommends a bottomup procedure, starting with tests. Thus, another interesting question is how to apply a bottom-up design of PDM and TCDM?
7.
ACKNOWLEDGMENTS
This work was partially supported by the Brazilian agencies CAPES, CNPq and FINEP.
8.
REFERENCES
[1] J. P. Almeida, R. Dijkman, M. Sinderen, and L. F. Pires. Platform-independent modelling in mda: Supporting abstract platforms. In Model Driven Architecture, volume 3599 of Lecture Notes in Computer Science, pages 174–188. Springer Berlin Heidelberg, 2005. [2] V. Aranega, A. Etien, and S. Mosser. Using feature models to tame the complexity of model transformation engineering. In ACM/IEEE 15th International Conference on Model Driven Engineering Languages and Systems MODELS 2012, pages –, 2012. [3] M. Asztalos, E. Syriani, M. Wimmer, and M. Kessentini. Simplifying model transformation chains by rule composition. In Models in Software Engineering, pages 293–307. 2011. [4] M. Azanza, D. Batory, O. D´ıaz, and S. Trujillo. Domain-specific composition of model deltas. In Theory and Practice of Model Transformations, pages 16–30, 2010. [5] F. P. Basso and R. M. P. Basso. Um relato de experiˆencia no desenvolvimento ´ agil de software com a mda. In First Brazilian Workshop on Model Driven Development, I BW-MDD, 2010. [6] F. P. Basso, L. B. Becker, and T. C. Oliveira. Using the fomda approach to support object-oriented real-time systems development. In Object and Component-Oriented Real-Time Distributed Computing, 2006. ISORC 2006. Ninth IEEE International Symposium on, pages 374–381, 2006. [7] F. P. Basso, L. B. Becker, and T. C. Oliveira. Uma solu¸ca ˜o para reuso e manuten¸ca ˜o de transformadores de modelos usando a abordagem fomda. In Simp´ osio Brasileiro de Engenharia de Software. Anais do 21o Simp´ osio Brasileiro de Engenharia de Software., 2007. [8] F. P. Basso, T. C. Oliveira, and K. Farias. Extending junit 4 with java annotations and reflection to test
[9]
[10] [11]
[12] [13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21] [22]
[23]
[24]
variant model transformation assets. In ACM Symposium on Applied Computing (SAC’14) (to appear), 2014. F. P. Basso, R. M. Pillat, T. C. Oliveira, and L. B. Becker. Supporting large scale model transformation reuse. In 12th International Conference on Generative Programming: Concepts & Experiences (GPCE’13), pages 169–178, 2013. S. Bayern. JSTL in Action. Manning Publications, 2002. D. Benavides, S. Segura, and A. Ruiz-Cort´es. Automated analysis of feature models 20 years later: A literature review. Inf. Syst., 35(6):615–636, Sept. 2010. J. B´ezivin. On the unification power of models. Software and System Modeling, 4(2):171–188, 2005. G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide (2nd Edition). Addison-Wesley, 2005. B. Burke and R. Monson-Haefel. Enterprise JavaBeans 3.0: Developing Enterprise Java Components. O’Reilly, 2006. C. Corrˆea, T. Oliveira, and C. Werner. Towards coupled evolution of metamodels, models, graph-based transformations and traceability links. In 25th International Conference on Software Engineering and Knowledge Engineering, SEKE 2013, Boston, USA, June 27-29 2013, 2013. K. Czarnecki. Overview of generative software development. In Proceedings of the 2004 international conference on Unconventional Programming Paradigms, UPP’04, pages 326–341, 2005. K. Czarnecki and S. Helsen. Classification of model transformation approaches. In OOPSLA’03 Workshop on Generative Techniques in the Context of Model-Driven Architecture, 2003. A. Etien, V. Aranega, X. Blanc, and R. F. Paige. Chaining model transformations. In Proceedings of the First Workshop on the Analysis of Model Transformations, AMT ’12, pages 9–14, 2012. A. Etien, A. Muller, T. Legrand, and X. Blanc. Combining independent model transformations. In Proceedings of the 2010 ACM Symposium on Applied Computing, SAC ’10, pages 2237–2243, 2010. P. Fernandes, C. Werner, and L. Murta. Feature modeling for context-aware software product lines. In International Conference on Software Engineering and Knowledge Engineering (SEKE’2008), SEKE 2008, pages 758–763, 2008. C. Guy, B. Combemale, S. Derrien, J. Steel, and J.-M. J´ez´equel. On model subtyping. pages 400–415, 2012. J. Hutchinson, J. Whittle, M. Rouncefield, and S. Kristoffersen. Empirical assessment of mde in industry. In Proceedings of the 33rd International Conference on Software Engineering, ICSE ’11, pages 471–480, 2011. F. Jouault and I. Kurtev. On the architectural alignment of atl and qvt. In Proceedings of the 2006 ACM symposium on Applied computing, SAC ’06, pages 1188–1195, 2006. K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
M. Huh. Form: A feature-oriented reuse method with domain-specific reference architectures. Ann. Softw. Eng., 5:143–168, Jan. 1998. A. Kleppe, J. Warmer, and W. Bast. Mda explained: The model driven architecture: Practice and promise, 2003. J. M. K¨ uster, T. Gschwind, and O. Zimmermann. Incremental development of model transformation chains using automated testing. In Model Driven Engineering Languages and Systems, pages 733–747, 2009. R. E. Lopez-Herrejon, A. Egyed, S. Trujillo, J. de Sosa, and M. Azanza. Using incremental consistency management for conformance checking in feature-oriented model-driven engineering. In VaMoS’10, pages 93–100, 2010. MDArte wiki hosted as a mda brazilian government initiative for public software repository. av. at http://www.softwarepublico.gov.br/dotlrn/clubs/ mdarte/xowiki/, 2013. M. Mendonca and D. Cowan. Decision-making coordination and efficient reasoning techniques for feature-based configuration. Science of Computer Programming, 75(5):311 – 332, 2010. R. M. Pillat, F. P. Basso, T. C. Oliveira, and C. M. L. Werner. Ensuring consistency of feature-based decisions with a business rule system. In Proceedings of the Seventh International Workshop on Variability Modelling of Software-intensive Systems, VaMoS ’13, pages 15:1–15:8, 2013. M. Rosenm¨ uller, N. Siegmund, M. Pukall, and S. Apel. Tailoring dynamic software product lines. SIGPLAN Not., 47(3):3–12, Oct. 2011. B. Tekinerdo˘ gan, S. Bilir, and C. Abatlevi. Integrating platform selection rules in the model driven architecture approach. In Proceedings of the 2003 European conference on Model Driven Architecture: foundations and Applications, MDAFA’03, pages 159–173, 2005. T. Th¨ um, C. K¨ astner, F. Benduhn, J. Meinicke, G. Saake, and T. Leich. Featureide: An extensible framework for feature-oriented software development. Science of Computer Programming, (0):–, 2012. D. A. Turner and J. Chae. Java Web Programming with Eclipse. CreateSpace Independent Publishing Platform, 2010. B. Vanhooff, D. Ayed, and Y. Berbers. A framework for transformation chain development processes. In Proceedings of the ECMDA Composition of Model Transformations Workshop, pages 3–8, 2006. M. V¨ olter and I. Groher. Handling variability in model transformations and generators. In Proceedings of the 7th OOPSLA Workshop on Domain-Specific Modeling (DSM’07), 2007. M. Volter and E. Visser. Product line engineering using domain-specific languages. In Software Product Line Conference (SPLC), 2011 15th International, pages 70–79, 2011. A. Yie, R. Casallas, D. Deridder, and D. Wagelaar. Realizing model transformation chain interoperability. Software & Systems Modeling, 11(1):55–75, 2012.
