Top Banner
Xpand: A Closer Look at the model2text Transformation Language Benjamin Klatt Chair for Software Design and Quality (SDQ), Institute for Program Structures and Data Organization (IPD), University of Karlsruhe, Germany 06. July 2007 [email protected] http://sdq.ipd.uka.de Abstract. Model-Driven Software Engineering is often constituted as the next level of software development. Since today it is rarely possible to directly execute models they have to be translated into artifacts to be used for further processing. The Xpand language is developed as part of the openArchitectureWare project for such a transformation. This paper provides an overview of the language itself and its context. Furthermore it draws a comparison to other model2text languages. While there is no standardization for model2text transformation right now, the challenge is to find the right language for certain purposes. The main contribution of this paper is to support this selection by delivering a more detailed insight to the Xpand language. Key words: MDSD, model2text, Xpand, transformation, openArchitectureWare
20
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Benjamin.klatt Xpand

Xpand:A Closer Look at the model2text

Transformation Language

Benjamin Klatt

Chair for Software Design and Quality (SDQ),Institute for Program Structures and Data Organization (IPD),

University of Karlsruhe, Germany06. July 2007

[email protected]

http://sdq.ipd.uka.de

Abstract. Model-Driven Software Engineering is often constituted asthe next level of software development. Since today it is rarely possibleto directly execute models they have to be translated into artifacts to beused for further processing. The Xpand language is developed as part ofthe openArchitectureWare project for such a transformation.This paper provides an overview of the language itself and its context.Furthermore it draws a comparison to other model2text languages. Whilethere is no standardization for model2text transformation right now, thechallenge is to find the right language for certain purposes. The maincontribution of this paper is to support this selection by delivering amore detailed insight to the Xpand language.

Key words: MDSD, model2text, Xpand,transformation, openArchitectureWare

Page 2: Benjamin.klatt Xpand

2 Benjamin Klatt

1 Introduction

Software development started with programming code that was directly exe-cutable by machines. The next generation are imperative languages like c, whichprovide some common libraries for system functionality and can be programmedwidely independent from the underlying processor architecture. The currentlyso-called state-of-the-art programming languages are object-oriented ones likeJava or C++.

Model-Driven Software Development (MDSD) [SV06] or Model-Driven Ar-chitecture (MDA) as it is called by the Object Management Group (OMG) isthe next level of software development. It focuses more on the software designthan on its implementation. The main target of this paradigm is to create modelsin an efficient and domain-specific way. This is accomplished by using domain-specific languages and generating the software from these models. The benefitsof this development process are efficiency, quality, maintainability and solutionfocus.

Currently most software systems still require compiled code that is executedon the software platform. Code or text generation is an essential step in theMDSD process. Textual transformations are nearly as old as the software de-velopment discipline itself. As a result there are many solutions available today.Someone who wants to start with MDSD has to find the right one for their ownrequirements. It becomes clear very soon that efficient and reliable model2texttransformation requires more than simple text replacement. One of the purposesof this paper is to give a closer look at Xpand, its concepts and its environmentto help answering the question of whether Xpand is the right solution for a spe-cific project. To better appreciate the considered aspects Xpand is compared tosome related languages.

The openArchitectureWare platform [ope07a] is one of the leading MDSDtools. It is developed as an open source project led by a core team who haslong time experience in model-driven software development. The platform hasbeen developed to build a tool that can be used in practice with the currentstate-of-the-art development technologies. [VK06]

Xpand is the domain-specific model2text transformation language of theproject. Templates are written in this language and used by the generator thatis linked to the development workflow of the platform.

2 The Xpand Language

2.1 Purpose and Development

Xpand was developed from scratch as a part of the openArchitectureWare plat-form (oAW). [ope07a]. While there are already many template languages avail-able, the authors of the framework have realized that an effective template devel-opment is only possible with an easy-to-learn, domain-specific language (DSL)for code generation, as well as with good tool support. With this focus, theXpand language itself has a small but sufficient vocabulary [EK06]. Beside of

Page 3: Benjamin.klatt Xpand

Xpand Language Analysis 3

its own capabilities, it can access functions implemented in the Xtend program-ming language, which is another domain-specific language that is contained inthe oAW framework.All of the Xpand developers are practitioners and have their focus on the ap-plication of the tools [VK06]. So while there might be a lot of things that areself-evident for language designers, the framework is coined by a lot of experiencethat comes from working in projects.

2.2 Application

Workflow The openArchitectureWare system is based on a workflow enginewhich executes different processing steps, like model instantiation, validation,model2model and model2text transformations. Figure 1 shows an example work-flow. The components can be configured arbitrarily so that it is possible to parsemultiple models and combine them into an internal abstract syntax graph. Also,multiple transformers for model2model transformations with a validation stepafter each transformation could be configured, as well as multiple generators fordifferent target artifacts.

Fig. 1. oAW example workflow

In this workflow the code generation (or model2text transformation) step willbe linked to the workflow definition.The workflow is defined in an XML descriptor file. A generator can be config-ured as shown in Example 1. First of all, the generator class is defined in thecomponent tag. Inside this tag the required meta models are referenced so thatthey can be accessed by the generator. Then, the main template that will be pro-cessed is referenced. The last more complex outlet tag sets the target directoryfor the generated artifacts and it includes the JavaBeautifier to produce betterformatted Java code.

Example 1.

...<component id="generator"

class="org.openarchitectureware.xpand2.Generator2">

Page 4: Benjamin.klatt Xpand

4 Benjamin Klatt

<metaModel idRef="emf"/><metaModel idRef="uml2"/><metaModel idRef="profile"/><expand value="Template::define FOR mySlot"/><outlet path="main/src-gen"><postprocessorclass="org.openarchitectureware.xpand2

.output.JavaBeautifier"/></outlet>

</component>...

Xpand itself is independent from the type of the source model. Differentsource models are handled by a parser linked to the openArchitectureWareworkflow. Parsers can be written for any kind of source model but openArchi-tectureWare provides out-of-the-box parsers for EMF, Eclipse-UML2, differentUML-Tools (MagicDraw, Poseidon, Enterprise-Architect, Rose, XDE) and tex-tual models using the Xtext framework as well as for XML and Visio.

Tool Support One of the biggest benefits of the 4.x generation of the openAr-chitectureWare is the extended tool support. It is widely based on the EclipseRich Client Platform (RCP) [ML06]. One of the plug-ins developed for this envi-ronment is the Xpand-specific editor (figure 2). This editor provides state-of-the-art programming support such as code completion and syntax highlighting andcoloring. Furthermore it has a built-in metamodel consideration, which meansthat custom defined metamodels are supported by the editor if they are accessi-ble by it (i.e. if the editor has access to your UML2 profile).

Fig. 2. Screenshot of the Xpand Editor

2.3 Template Files

Xpand templates are composed of one or more template files that are textualdocuments with the file extension .tpl. The generator linked to the openArchitec-tureWare workflow references one of these templates that acts as a point-of-entry

Page 5: Benjamin.klatt Xpand

Xpand Language Analysis 5

and references other templates to execute them. The templates can be organizedwithin packages that are physically stored in directories and subdirectories inalmost the same way Java packages are. This provides possibilities for reuse andorganization.

2.4 Vocabulary

As mentioned in the purpose and development section 2.1 the target of thelanguage design was to provide an easy to learn language. With this in mind,the vocabulary is very small and intuitively understandable. The following is ashort overview of the vocabulary. Please refer to the Xpand reference for furtherinformation [EK06].

EscapingEvery template language needs some characters to separate the template expres-sions from the static text fragments for the output. It is a best practice [VK06]to use escaping characters which do not occur in the generated artifacts. For theXpand language the French quotation marks (”guillemots”) have been chosen.

General Template StructureThe template in example 2 imports a model definition, loads an extension anddefines a template section for a simple Java class that is applied to an elementof the type Entity. Following a short overview of the different directives is given.

Example 2.

�IMPORT meta::model��EXTENSION my::ExtensionFile�

�DEFINE javaClass FOR Entity��FILE fileName()�package �javaPackage()�;public class �name� {// implementation

}�ENDFILE�

�ENDDEFINE�

Basic Template Elements

DEFINEThis directive marks a template definition. A template has a name and is alwaysassigned to a specific element type. Collection types are allowed, too. The typedefinition is also used for template polymorphism. I.e. if a template should bedefined for elements of a subtype of the type Entity in the example 2 the DEFINEsection will be declared with the subtype instead of Entity.

Page 6: Benjamin.klatt Xpand

6 Benjamin Klatt

IMPORTThis gives access to all templates in a specific namespace. In example 2 theidentifier Entity is used instead of the fully-qualified name meta::model::Entity.

EXTENSIONThis directive loads extensions written in the Xtend language.

Control Flow

EXPANDThis directive is used to execute a DEFINE block for the specified element type.(See Example 3)

Example 3.

..�DEFINE javaClass FOR Entity�..�EXPAND methodSignature FOR this.methods�..

�ENDDEFINE�

�DEFINE methodSignature FOR Method�...

�ENDDEFINE�..

FOR and FOREACH (within EXPAND)These directives are used to apply a template on a collection of elements but inslightly different ways.FOR simply executes the referenced template for each element resulting fromthe given expression as shown in example 3. This might also be a single element.FOREACH instead always requires a collection to work on and therefor providesthe capability to define a separator that is added between each of the elementprocessing. (see example 4)

Example 4.

�EXPAND paramTypeAndName FOREACH params SEPARATOR ","�

FOREACH (single occurrence)If foreach is used as a directive, it defines a loop control flow as in many otherprogramming languages. Example 5 shows such a loop with the available options.

Example 5.

Page 7: Benjamin.klatt Xpand

Xpand Language Analysis 7

�FOREACH expression AS variableName [ITERATOR iterName][SEPARATOR expression]�

a sequence of statements using variableName toaccess the current element of the iteration

�ENDFOREACH�

IFIf is used as in many programming languages to mark a block that is onlyexecuted if a condition is evaluated to true.

File Generation

FILEThe file directive marks a section which is executed and the generated text iswritten to the file defined by this directive. In the basic template structure ex-ample in example 2 the directive is used to write a distinct file for each generatedJava class. In this example an Xtend function is called to compute the name ofthe file to write to.

Protected Regions

PROTECTA general problem is to protect manual added code in the generated artifactsof being overridden when the generation is executed again. Xpand provides socalled protected regions which are marked by the PROTECT directive for thispurpose.

Miscellaneous

LETThe LET operator is used to declare variables and their content. LET is designedto define a block in which the result of an expression is bound to a variable. InExample 6 the fully qualified name of a class is stored in a variable named fqn.

Example 6.

�LET packageName + "." + className AS fqn�the fully qualified name is: �fqn�;

�ENDLET�

ERRORThe error directive can be used to stop the template processing. Even if it ispossible with this directive it is recommended to implement model checks earlierin the workflow using the Check language of openArchitectureWare. [Eff06]

COMMENTSComments look similar to those used in DOS and Windows batch scripts. (seeexample 7)

Page 8: Benjamin.klatt Xpand

8 Benjamin Klatt

Example 7.

�REM�Comment�ENDREM�

WHITESPACESIn template languages it is always necessary to have influence on the gener-ated whitespaces. Otherwise it could happened that the generated artifacts areflooded with not required whitespaces and empty lines. Xpand provides the pos-sibility to mark directives with a minus sign if they should not generate a newline or whitespaces. The code in example 8 produces only one line.

Example 8.

�IF hasPackage-�package �InterfacePackageName�;

�ENDIF-�

AOPAspect Oriented Programming (AOP) is a common paradigm to couple cross-cutting aspects in the implementation. Xpand also supports this paradigm forthe template definition with the AROUND syntax. By this, existing templatescan be extended. As shown in Example 9 point cuts define the elements thatshould be enhanced with the aspect definition.

Example 9.

�AROUND [pointcut]�do stuff

�ENDAROUND�

2.5 Language Features

Czanecki and Helsen have designed a feature model for model transformationapproaches. The model is shown in figure 3 [CH06]. This model is a good guide-line to get an overview of the concepts used in a model transformation language.The following sections discuss how Xpand can be categorized according to thismodel.

Transformation Rules The transformation rules feature consists of multiplesub features. Figure 4 shows the subtree of the model.

The target or so called out-domain always consists in textual artifacts whichcould belong to a specific programming language. The source domain handled byXpand is the abstract syntax graph that was instantiated by the openArchitec-tureWare workflow and handed over to the generator. This is also described asthe in-Domain. The abstract syntax graph is an intermediate structure of oAW.Xpand itself does not use any intermediate structure but it becomes decoupled

Page 9: Benjamin.klatt Xpand

Xpand Language Analysis 9

Fig. 3. Feature Model Overview taken from [CH06]

Fig. 4. Transformation feature model - Transformation rules subtree

from the type of the source model by linking an according parser to the oAWworkflow.

Xpand provides a simple unidirectional transformation. The only syntacticalseparation in the template definitions is between the template code and the staticcontent.

Application conditions are only provided in form of the IF directive withinthe templates. Parametrization is possible in a restricted way in the generatorconfiguration by defining the template that is used as point-of-entry and canhold parametrization settings. A real properties file can only be loaded and usedin the workflow definition.

In the template definition Xpand provides access to the source metamodel.Working on this meta level is some kind of reflection access to the source model.Aspect orientation is an explicitly supported feature of Xpand. This already hasbeen discussed in the in the Vocabulary section.

Rule Application Strategy Xpand has a strict strategy based on templatereferences and polymorphism rules. This concept ensures that the rules are ap-plied in a deterministic way.

Rule Scheduling Xpand rule scheduling can be defined by the user in an ex-ternal explicit form by building a template hierarchy and referencing from onetemplate to another. The scheduling can also be defined implicitly by using thepolymorphism capabilities of the language. So the templates will be executed ina deterministic order starting from the first template referenced by the gener-ator. This concept protects against any scheduling conflicts. With the foreachdirective a looping construct is provided. Depending on the source meta-model

Page 10: Benjamin.klatt Xpand

10 Benjamin Klatt

it is possible to call templates recursively as well. Czarnecki and Helsen define anXOR relationship in their feature model for the looping and the recursion fea-tures but one does not exclude the other as seen in the case of Xpand. The lastfeature considered in the subtree is the phasing. Phasing is about the structureof the transformation workflow. Xpand is used within the openArchitectureWareworkflow which handles the phasing and the templates are only executed.

Rule Organization Xpand has a modularity mechanism which enables to or-ganize the templates in packages and to import complete template namespaces.The packages can be defined flexible but the DEFINE directive is coupled to theelement type that is processed. So it is more coupled to the source then to thetarget structure. Additionally to this mechanism template polymorphism is sup-ported and by this Xpand supports all reuse techniques described by Czaneckiand Helsen.

Source-Target Relationship This relationship is about the target and sourcemodels required by the language. This concerns more to model2model languagesbecause the target of a model2text transformation is always a text representa-tion. This applies to Xpand as well.

Incrementality As with the Source-Target Relationship this definition is notan interesting feature for Xpand. It transfers a model from an abstract syntaxgraph to a textual representation and the rules defined for an abstract syntaxgraph can not be applied to text fragments. So there is no possibility to transferthe model incremental.

Tracing There is no direct support for tracing but it could be realized with theAspect Oriented Programming support.

Directionality As the most model2text transformation languages Xpand doesnot provide round trip functionality and performs an unidirectional transforma-tion.

2.6 Perspective

On the roadmap of the openArchitectureWare project an issue for version 5 isa new version of the Xtend language. The new Xtend++ should unify the lan-guages Xtend, Check and Xpand [ope07b].It is unclear which impact the OMG model2text language specification [Gro06]will have on the language. It defines a language on itself which has to be sup-ported by tools to become certified to the standard. It is not a general specifi-cation how model2text languages should be designed.

Page 11: Benjamin.klatt Xpand

Xpand Language Analysis 11

3 Comparison to other model2text Languages

3.1 Preface

There are many languages available which are able to produce text artifacts outof different model definitions. As with most technologies, the best solution de-pends on the concrete requirements. This comparison gives attention to somerepresentative languages and procures key factors to keep in mind when a so-lution is evaluated. Further more it exposes advantages and disadvantages ofXpand over other languages which come in when it is compared to languagesnot covered here.

3.2 Considered Languages

To limit the number of languages to a reasonable set, the languages mentioned inthe Eclipse model2text project [Fou07] are handled in this section. The Websitelists the following ones:

– JET (Java Emitter Templates)– MTL (Model to Text Language)– M2T (Model to Text)

Furthermore the Object Management Group (OMG) currently develops theirown language specification for model2text transformation. This specification willbe discussed in detail in a later section.Simple text replacement approaches like XSLT are not covered here. They pro-vide less functionality than JET and in comparison to Xpand they come up witha worse result.

JET JET (Java Emitter Templates) is an open source component like the ope-nArchitectureWare platform. It provides a framework and facilities for code gen-eration. JSP like template files are used and by this it makes it easy to learnfor developers already familiar with this technology. It is easy to extend withcustom tags like it is possible for JSPs.

Tool SupportJET is strongly supported by tools integrated in the eclipse IDE. A transforma-tion specific project can be created in eclipse and provides all required files (seefigures 5 and 6). Furthermore a JET-specific editor and a launch configurationto start a transformation run are provided.

Model AccessJET by default requires an XML file as input. This does not have to be anyspecific XML format and does not have to be related to software modeling.XPath (XML Path Language) [W3C07] is used to access different nodes in theXML source and to navigate between the elements. XPath is a wide-spreadlanguage so there are many developers already familiar with it.

Page 12: Benjamin.klatt Xpand

12 Benjamin Klatt

Fig. 5. JET - project wizard

Fig. 6. JET - basic file structure

Page 13: Benjamin.klatt Xpand

Xpand Language Analysis 13

When a JET template is developed and saved in the JET editor a Java class isgenerated out of it. This template class can be called directly from other Javacode. So it is possible to program a custom parser that prepares the source modelto be transformed by the template class.

Template definition and executionA JET transformation can be imagined as a blueprint which is applied to asource model. The source model is sometimes just called parameter set becauseit defines the values which should be used when the blueprint is applied. A JETtransformation can be illustrated as: Parameters + Blueprint = Desired Artifacts[AM07].

ExampleA simple transformation source that defines different persons can look like inexample 10.

Example 10.

<app middle="Hello" ><person name="Chris" gender="Male" /><person name="Nick" gender="Male" /><person name="Lee" gender="Male" /><person name="Yasmary" gender="Female" />

</app>

Example 11 is a transformation template to generate a class for a person element.

Example 11.

class <c:get select="$currPerson/@name" />Person {public String getName() {return "<c:get select="$currPerson/@name" />";

}public void shout() {System.out.println("Hello!!!");

}}

The transformation processing is defined within a template file as in Example12. The process iterates over all person elements in the source XML and executesthe PersonClass Java template. The results are written into separate Java files.

Example 12.

<c:iterate select="/app/person" var="currPerson"><ws:file template="templates/PersonClass.java.jet"path="{$org.eclipse.jet.resource.project.name}/

{$currPerson/@name}.java"/></c:iterate>

Page 14: Benjamin.klatt Xpand

14 Benjamin Klatt

DiscussionJET is based on existing and established technologies. It is easy to find developerswho are already familiar with them. A project is very easy to be set up within ashort time. On the other side there is no domain-specific support for the model-driven software development. For example it is not possible to validate a templatewhen it is saved like the Xpand editor does. The state-of-the-art MDSD handlesquite complex models and for larger projects it becomes hard to handle thecomplexity without extensive tool support for the domain.

MTL MTL is an implementation of the OMG model2text language standard. Itis still in development phase and nothing has been released yet. The comparisonresults for MTL should be nearly the same as in the comparison with the OMGstandard done later in this paper.

M2T M2T can not be seen as a competitor to Xpand. The M2T (model2text) isan eclipse project with focus on model2text transformation. It is not a transfor-mation language on its own but provides basic components which can be used byother projects like JET, Xpand or MTL. There are two main components calledM2T core and M2T shared. While the first one is an invocation framework fortransformations the later one is an infrastructure component for different trans-formation languages.

3.3 Object Management Group (OMG) Standardization

While the OMG works hard on standardizations in the Model-Driven Architec-ture (MDA) environment, they investigate in the model2text area, too. In 2004there was the first Request for Proposal (RFP) of a ”Meta Object Facility Modelto Text Transformation Language”. For this RFP a revised submission has beenpublished in August 2006 [Gro06]. Because there are a lot of standardizationssuccessfully established by the OMG and their specification is quite new, it makessense to take a closer look to this standard in comparison to Xpand.

Basic Language Concept The OMG submission contains a language specifi-cation developed by the submitting companies. One of the basic ideas is to reusealready existing standards as much as possible. Especially MOF 2.0 and QVTare used. Tools have to adopt the language to get certified with a specific con-formance level. As described in the following section there are some differencesbetween Xpand and the OMG model2text language. Tools which conform to theOMG standard are not conform to Xpand as well.

Syntax The OMG language syntax is nearly as simple as the one of Xpand.The transformations are defined as so called templates which can be organizedas modules in different namespaces. Also it contains many basic language el-ements such as Template, For and If. The elements which are handled in the

Page 15: Benjamin.klatt Xpand

Xpand Language Analysis 15

same way as in Xpand are not handled in this paper. Please refer to the OMGreference [Gro06] or the Xpand [EK06] reference for further information aboutthese elements.

Escape DirectionThe template definition can be defined in two different ways: text-explicit orcode-explicit. In the first style, the static text for the output is written as it isand the template tags are escaped (see Example 13).

Example 13.

@text-explicit[template public classToJava{c: Class}]class [c.name/]{...

}[/template]

In the code-explicit style, the template code and static text are escaped theother way around but with different markers as in example 14.

Example 14.

@code-explicittemplate public classToJava{c: Class}’class ’c.name’{...

}’/template

This is flexible and in some cases the templates may be shorter but it requirestools and developers to read different languages. It is the same when escapingcharacters other than the standard ones are used for the code-explicit style.Xpand only offers the text-centric style and requires to handle only one syntax.

Template EvaluationThe OMG specified that a module can extend other ones. If this is used a tem-plate is able to override other templates. This polymorphism is like the oneavailable in Xpand. Beside of this, the OMG specification has an extended han-dling for parameter collections. If the template definition requires a parameter oftype string and is referenced with a collection of strings it will be executed oncefor each string of the collection. This is an easy way to make the programmingof loops unnecessary. As a drawback this could lead to unexpected results. Ifthe required input parameter is a collection of objects and the template is calledwith a collection of collections it is undefined whether the template is executedonce at all or once per inner collection.

White Space HandlingXpand offers just one straight way to influence the handling of whitespaces. The

Page 16: Benjamin.klatt Xpand

16 Benjamin Klatt

OMG syntax instead does not offer a way to influence this manually. Explicitrules are defined how to generate whitespaces and new lines depending on theprocessed language directive.

QueriesThe OMG specification implements a directive to query the processed model.This makes it possible to collect elements which are not at the same place in themodel. Example 15 is an OMG query to build a collection of attributes to beprocessed by a template. Xpand only offers the possibility to access a collectionof objects in one path. Everything more complex has to be handled by Xtendfunctions.

Example 15.

[query public allOperations(c: Class):Set ( Operation )= c.operation->union( c.superClass->select(sc|sc.isAbstract=true)->iterate(ac : Class; os:Set(Operation)

= Set{}| os->union(allOperations(ac)))) /]

Protected AreasThe OMG specification provides so called protected areas for text manuallyadded to generated artifacts which should not be overridden when the trans-formation is processed again. The areas have to be marked in the generatedartifacts. How they have to be marked could not be specified in the templateand the specification says this has to be handled by the tool executing the trans-formation.

Xpand provides protected regions for this purpose. Xpand protected regionshave the possibility to specify the markers that should be used in the generatedtext. This makes the tool independent from the target syntax of the artifacts.The OMG requires the tool to know how comments are formatted in the targetlanguage.

MacrosThe OMG specification includes the definition of macros which could be reusedin the templates. In example 16 a simple macro which produces a comment isdefined and applied.

Example 16.

[macro comment (Body b)]/**[b/]*/[/macro]

usage:

[comment()]...

[/comment]

Page 17: Benjamin.klatt Xpand

Xpand Language Analysis 17

File OutputThe OMG file definition is nearly the same as provided by Xpand. The maindifference is an option to append the new generated text to the target file if italready exists. The specification mentions the production of log files as a purposeof this feature.

Discussion The OMG specification shows a lot of overlaps to the Xpand lan-guage. These overlaps identify a common set of reasonable features. But thebig difference is that Xpand is designed to be as small and straight forward aspossible. The small vocabulary is easy-to-learn and challenges are solved as easyas possible. The OMG however shows some conceptual inconsistencies. I.e. theyprovide a flexible template syntax by defining configurable escaping charactersfor the code-explicit language style but on the other hand they force the process-ing tool to know the comment style of the target languages to mark protectedregions.

To sum this up, in the combination with the tight integrated Xtend language,Xpand is at least as powerful as the OMG specification but much more straightforward to learn and to work with.

3.4 Advantages of Xpand

Domain-Specific Language Unlike many other solutions Xpand is a domain-specific model2text transformation language for the model-driven software devel-opment. It is a static typed language and offers better facilities to access modelstructures and to write and organize templates. This is an essential requirementfor professional MDSD. [VK06]

Source Model Support Xpand does not care about the source model becauseit processes the abstract syntax graph provided by the openArchitectureWareworkflow. It depends on the linked parser which reads in the model. openAr-chitectureWare comes with out-of-the-box parsers for common software models.Refer to section 2.2 for a list of the included parsers.

Utilization Since the 4.x generation the openArchitectureWare platform isavailable as a prepared distribution which includes eclipse and all required plug-ins. In the latest version there is a good tool support for template and workflowdevelopment and for their execution.

Easy Start-Up The language vocabulary is easy to learn and with its toolsupport someone can get in use with it very soon. This assessment is only aboutXpand and no other component related to it like Xtend or MDSD on the whole.

Page 18: Benjamin.klatt Xpand

18 Benjamin Klatt

Practical Experiences Xpand has been developed by a development teamwith a lot of practical experiences not only in the model-driven software devel-opment but in the general software development area as well. The language hasproof of value in tedium applications. Also it has been chosen by some projectswhere other languages like JET have come to their limitation. In most casesbecause of structural purposes. [ope07c]

Strong Community Even if it is not big yet the openArchitectureWare hasa potential and healthy community. Answers are given fast and professional inthe forum and the documentation provides a lot of tutorials, references andscreencasts as well. [ope07a]

3.5 Disadvantages of Xpand

Complexity As a part of openArchitectureWare, the concept and the applianceof the platform has to be understood to set up a transformation project. Thereare smaller frameworks like JET with a shorter ramp-up time.

Future plans As mentioned in the perspective section there are plans to inte-grate Xpand into a new version of the Xtend language. Even if the core developersare experienced with real world projects it can not be excluded that there willbe an effort required to refactor all templates for the next major release.

4 Conclusion

There are many text generation languages and frameworks available. Some with amore general purpose and others strongly connected to the model-driven softwaredevelopment. Xpand is one of the tight connected ones. The language itself iseasy to learn with a small vocabulary but is integrated with more powerfullanguages to handle quite complex requirements.

As shown in the advantages and disadvantages section Xpand is a good choicefor model-driven software development. It rules over many other languages be-cause of its domain-specific features and the practical experience in high levelMDSD. The openArchitectureWare platform is still young and complex. As withnearly every technology it depends on the concrete case whether Xpand is theright choice or not. For small projects that are not intended to grow and for whichit is more important to have a short start-up time Xpand and the openArchitec-tureWare platform may not be the right choice. Only if the development team isvery familiar with it and is able to set it up as easy as a JET project or anothersimple framework it would make sense to chose Xpand for small and limitedprojects.A similar reason is a high fluctuation of the development team if the developersare not in use with the openArchitectureWare but with technologies used by

Page 19: Benjamin.klatt Xpand

Xpand Language Analysis 19

other frameworks like JET. In this case it may be better to choose a solutionyour developers already have the required knowledge for.

Nevertheless in the end most projects that decide for a model-driven softwaredevelopment approach have the claim to do this on a high and professional level.For those it makes sense to start with openArchitectureWare and Xpand becauseof the long time investment and to ensure that the development does not runinto complexity problems. [ope07c]

Page 20: Benjamin.klatt Xpand

20 Benjamin Klatt

5 Appendix

List of Figures

1 oAW example workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Screenshot of the Xpand Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Feature Model Overview taken from [CH06] . . . . . . . . . . . . . . . . . . . . . . . 94 Transformation feature model - Transformation rules subtree . . . . . . . . 95 JET - project wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 JET - basic file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

References

[AM07] Chris Aniszczyk and Nathan Marz. Create more better code in eclipsewith jet. Internet, 2007. http://www.ibm.com/developerworks/opensource/library/os-ecl-jet/, last access 06/07/2007.

[CH06] Krzysztof Czarnecki and Simon Helsen. Feature-based survey of model trans-formation approaches. IBM Systems Journal, 45(3), 2006.

[Com07] AOSD Steering Committee. Aspect-oriented software development commu-nity. Internet, 2007. http://www.aosd.net/, last access 06/07/2007.

[Eff06] Sven Efftinge. Check - Validation Language, Reference Documentation, 2006.[EK06] Sven Efftinge and Clemens Kadura. OpenArchitectureWare 4.1 Xpand Lan-

guage Reference, 2006.[Fou07] The Eclipse Foundation. Eclipse modeling - m2t - home. Internet, 2007.

http://www.eclipse.org/modeling/m2t/, last access 06/07/2007.[Gro06] Object Management Group. Revised submission for: MOF Model to Text

Transformation Language (ad/2004-04-07), 2006.[ML06] Jeff McAffer and Jean-Michel Lemieux. Eclipse rich client platform. Addison-

Wesley, 2006.[ope07a] openarchitectureware. Official openarchitectureware homepage. Internet,

2007. http://www.openarchitectureware.org, last access 06/07/2007.[ope07b] openarchitectureware. openarchitectureware roadmap. Internet, 2007. http:

//wiki.eclipse.org/index.php/OAW_Roadmap, last access 06/07/2007.[ope07c] openarchitectureware. openarchitectureware success stories. Internet, 2007.

http://openarchitectureware.org/index.php?topic=success, last access06/07/2007.

[Pop04a] Remko Popma. Jet tutorial part 1 - introduction to jet. Internet, 2004. http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html, last ac-cess 06/07/2007.

[Pop04b] Remko Popma. Jet tutorial part 2 (write code that writes code). Internet,2004. http://www.eclipse.org/articles/Article-JET2/jet_tutorial2.

html, last access 06/07/2007.[SV06] Thomas Stahl and Markus Volter. Model driven software development. Wiley,

2006.[VK06] Markus Volter and Bernd Kolb. Best practices for model-to-text transforma-

tions. In Eclipse Summit Europe 2006. EclipseCon, 2006.[Vol07] Markus Volter. Modellgetriebene entwicklung von eingebetteten systemen.

In OOP 2007, Software meets Business. SigsDatacom, 2007.[W3C07] World Wide Web Consortium W3C. Xml path language - xpath. Internet,

2007. http://www.w3.org/TR/xpath, last access 06/07/2007.