all FREECO11-workshop-papers.pdf - trese

More documents

Recommendations

Info

from WebDSL code. A second code generator then merges (superimposes)partial classes and operations and produces the finalcode in the target language. Again, this is essentially the same asour approach. However, because Stratego/XT does not provide anydirect support for aspect-oriented transformations or code generations,Hemel et al. needed to introduce an explicit new intermediarylanguage, containing a large set of constructs only relevant for thesubsequent superimposition (e.g., @Class for representing a partialclass). Their approach is eased by the use of Stratego/XT, wheregenerated code is always handled as an abstract syntax tree ratherthan plain text. Instead, in our approach, code is generated as text,which is then merged in a separate step. This requires this text tobe parsed again in preparation for merging, making our approachperhaps a little less time efficient. At the same time, however, italso allows the use of simpler textual merges based on the sameinfrastructure.5. CONCLUSIONSIn this paper, we have proposed an approach applying notions ofsymmetric aspects to the domain of code generation. This approachseparates the specification of code generators from the specificationof their composition, providing more flexibility in choosing codegenerators that should be used for a particular generation task. Becauseit is a symmetric approach, it does not require any templateto be identified as the base template, enabling us to flexibly leaveout or re-arrange code generators as required. Because the weavinghappens at the level of generated code, there is no need for scaffoldingin the form of empty generator rules. Because we use syntacticmerging, the approach can take into account syntactic constraints ofthe language of the generated code. We have successfully appliedour approach to the generation of EJB code from a class model [17],and are looking to further evaluate it with more case studies as wellas in a comparative study with other generation approaches.AcknowledgementsThis work has been funded by the European Commission underFP6 STREP AMPLE and FP7 Marie-Curie IEF RIVAR. The authorswish to thank Dimitrios Kolovos, Louis Rose, and RichardPaige for help with and discussion about the Epsilon framework,and Jon Whittle for useful feedback on an earlier draft.6. REFERENCES[1] Sven Apel, Christian Kästner, and Christian Lengauer.FEATUREHOUSE: Language-independent, automatedsoftware composition. In Stephen Fickas, Joanne Atlee, andPaola Inverardi, editors, Proc. 31st Int’l Conf. on SoftwareEngineering (ICSE’09), pages 221–231. IEEE ComputerSociety, 2009.[2] Ruzanna Chitchyan, Phil Greenwood, Americo Sampaio,Awais Rashid, Alessandro Garcia, and Lyrene Fernandesda Silva. Semantic vs. syntactic compositions inaspect-oriented requirements engineering: An empiricalstudy. In Proc. 8th ACM Int’l Conf. on Aspect-OrientedSoftware Development (AOSD’09), pages 149–160. ACM,2009.[3] Eclipse Foundation. Eclipse web site. Published on-line:http://www.eclipse.org/.[4] Sven Efftinge, Peter Friese, Arno Haase, Dennis Hübner,Clemens Kadura, Bernd Kolb, Jan Köhnlein, Dieter Moroff,Karsten Thoms, Markus Völter, Patrick Schönbach, MoritzEysholdt, and Steven Reinisch. openarchitectureware xpanddocumentation. Published on-line:http://www.openarchitectureware.org/pub/documentation/4.3.1/html/contents/core_reference.html#xpand_reference_introduction, 2009.[5] William H. Harrison, Harold L. Ossher, and Peri L. Tarr.Asymmetrically vs. symmetrically organized paradigms forsoftware composition. Technical Report RC22685, IBMResearch, 2002.[6] Zef Hemel, Lennart C. L. Kats, Danny M. Groenewegen, andEelco Visser. Code generation by model transformation: Acase study in transformation modularity. Software andSystems Modelling, 9(3):375–402, June 2010. Publishedon-line first at www.springerlink.com.[7] Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. TCS: ADSL for the specification of textual concrete syntaxes inmodel engineering. In Stan Jarzabek, Douglas C. Schmidt,and Todd L. Veldhuizen, editors, Proc. 5th Int’l Conf. onGenerative Programming and Component Engineering(GPCE’06), pages 249–254. ACM, 2006.[8] Dimitrios Kolovos, Richard Paige, Louis Rose, and FionaPolack. The Epsilon Book. Published on-line: http://www.eclipse.org/gmt/epsilon/doc/book/,2009.[9] Tom Mens. A state-of-the-art survey on software merging.IEEE Transactions on Software Engineering, 28(5):449–462,2002.[10] Jon Oldevik and Øystein Haugen. Higher-ordertransformations for product lines. In Tomoji Kishi and DirkMuthig, editors, Proc. 11th Int’l Software Product Line Conf.(SPLC’07), pages 243–254. IEEE Computer Society, 2007.[11] Jon Oldevik, Tor Neple, Roy Grønmo, Jan Aagedal, andArne-J. Berre. Toward standardised model to texttransformations. In A. Hartman and D. Kreische, editors,European Conf. on Model Driven Architecture – Foundationsand Applications (ECMDA-FA’05), pages 239–253, 2005.[12] Louis M. Rose, Richard F. Paige, Dimitrios S. Kolovos, andFiona A. Polack. The Epsilon generation language. In InaSchieferdecker and Alan Hartman, editors, Proc. 4thEuropean Conf. on Model Driven Architecture(ECMDA-FA’08), pages 1–16. Springer, 2008.[13] Dave Steinberg, Frank Budinsky, Marcelo Paternostro, andEd Merks. EMF: Eclipse Modeling Framework.Addison-Wesley Professional, 2nd edition, 2009.[14] Jonne van Wijngaarden and Eelco Visser. Programtransformation mechanics: A classification of mechanismsfor program transformation with a survey of existingtransformation systems. Technical Report UU-CS-2003-048,Institute of Information and Computing Sciences, UtrechtUniversity, May 2003.[15] Markus Völter and Iris Groher. Handling variability in modeltransformations and generators. In Proc. of the 7th OOPSLAWorkshop on Domain-Specific Modeling, 2007.[16] Jules White, Jeff Gray, and Douglas C. Schmidt.Constraint-based model weaving. Transactions onAspect-Oriented Software Development, Special Issue onAspects and Model-Driven Engineering, 5560(6):153–190,2009.[17] Steffen Zschaler and Awais Rashid. Symmetriclanguage-aware aspects for modular code generators.Technical Report TR-11-01, King’s College London,Department of Informatics, 2011.
Open, extensible composition models(extended abstract) ∗Ian PiumartaAcademic Center for Computing and Media Studies, Kyoto University, JapanViewpoints Research Institute, Glendale, CA, USAian@vpri.orgABSTRACTSimple functional languages like LISP are useful for exploringnovel semantics and composition mechanisms. That usefulnesscan be limited by the assumptions built into theevaluator about the structure of data and the meaning ofexpressions. These assumptions create difficulties when aprogram introduces a composition mechanism that differssubstantially from the built-in mechanism of function application.We explore how an evaluator can be constructedto eliminate most built-in assumptions about meaning, andshow how new composition mechanisms can be introducedeasily and seamlessly into the language it evaluates.1. INTRODUCTIONAdding a new composition mechanism to a programminglanguage can entail defining a corresponding data type T ,creating and maintaining values of that type, adding a syntacticoperator to combine those values with one or moreother values, and providing an algorithm that determinesthe compositional meaning of those combinations. Valuesof T retain persistent information needed by the composition.These values can also act as syntactic operators, if theintrinsic evaluation mechanism associates their presence ina combination with behaviour specific to T . The algorithmprovides semantics for the composition, expressed as furthercompositions or as primitive operations of the language, accordingto the values being combined.The above can be achieved within the basic abstractionsof some programming languages, although unnecessary complexityand obfuscation arise whenever those abstractionslimit direct access to the data and algorithms implementingthe composition. If supporting mechanisms can be introducedat the meta level of the host language then these limitationsdo not arise, the interface presented to the programmercan deal directly and efficiently with relevant information,and the new composition appears as a natural extensionof the language—qualitatively indistinguishable froman intrinsic mechanism.∗ The full paper [4] is available online.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.FREECO’11, July 26, 2011, Lancaster, UKCopyright 2011 ACM 978-1-4503-0892-2/11/07 ... $10.00The introduction of supporting mechanisms at the metalevel will be illustrated using a functional language derivedfrom McCarthy’s LISP [1, 2]. Section 2 introduces this languageand its evaluator. Section 3 describes modificationsin its meta level to accommodate user-defined compositions.Section 4 presents several examples of composition mechanismsadded to the language. Section 5 discusses the workand places it in context. Section 6 offers concluding remarks.1.1 Typographic conventionsURLs and code are set monospaced. In code the name of a identifier is enclosed by angle brackets and access tothe fields of its values is designated -field. (, %and - are letters having no special significance.) Primitivebehaviour is written as {pseudo code} .2. A MINIMAL FUNCTIONAL LANGUAGEFigure 1 defines an evaluator for a functional language ofsymbolic expressions represented as lists in polish notation.The evaluator corrects several semantic inadequacies of LISP(described by Stoyan [5]) and is metacircular (written in thelanguage it evaluates). The language provides:• lists and atomic values, including symbols• primitive functions called s• symbolic functions (closures) called s• a object that encapsulates another applicablevalue and prevents argument evaluation• predicates to discriminate between the above types• built-in s to access the contents of these values• awaytocall the primitive behaviour of a • a quotation mechanism to prevent evaluation of literalsThe interpretation of structures is defined by the usualpair of functions eval and apply. eval takes an expression(simple or complex) and yields its value in the context ofan environment of bound names. apply takes a complexexpression, split into a function part and its arguments,and yields the result of applying the former to the latterin the context of an environment of bound names. (As inLISP [2]: evlis evaluates each element in a list and returnsa list of the results, pairlis extends an environment bybinding a list of names to a list of values, and assoc finds apreviously-bound name in an environment.)A global initial environment contains bindings for primitives( values) and control structures (s ors wrapped in a ). Assignment and mutablestate are supported via primitives (as they were in LISP [2,pp. 70ff ]).
Page 1 and 2: FREECO-11Table of ContentsTable of
Page 3 and 4: 1 Policy (Id = ”Service Levels”
Page 5 and 6: the level of assertions. On the oth
Page 7 and 8: An association-based model of dynam
Page 9 and 10: that, when substituted back into r
Page 11 and 12: This suggests using the association
Page 13 and 14: class-based languages like Java and
Page 15 and 16: • The keywords final in Java, con
Page 17 and 18: Composing heterogeneous software wi
Page 19 and 20: 3. APPROACHOur approach consists of
Page 21 and 22: example, the naming convention we s
Page 23 and 24: 2. We present a novel approach and
Page 25: CG Template 1CG Template 2...CodeSl
Page 29 and 30: (define eval (lambda (exp env)(appl
Page 31 and 32: defined to combine values into comp
Page 33 and 34: • a proof that the model transfor
Page 35 and 36: have been proposed that allow parts
Page 37 and 38: FREECO-11Author IndexAuthor IndexBe

all FREECO11-workshop-papers.pdf - trese

Create successful ePaper yourself

Delete template?

Save as template?