all FREECO11-workshop-papers.pdf - trese

More documents

Recommendations

Info

tual machine). For example, some level of reflection is a necessity.Secondly, composability: a key question is whethermultiple composition operators, in particular when appliedto the same location (e.g. same field), will still yield thedesired behavior. From our experience with Co-op we distinguishseveral issues for composing composition operators:• Multiple operators should be applicable to the sameprogram location.• The semantics of co-located operators should be compatible:this may require a proper design of the compositionoperator library.• The order of applying composition operators may makea difference.• Some operators are by design incompatible.• Hence one needs to express ordering, exclusion and coexistenceconstraints between operators. These can begeneral constraints, or application-specific constraints.We plan to perform additional case studies of implementingcomposition mechanisms in Co-op/II and to improve ourprototype in several ways. As mentioned already in section3, often developers depend on specific compositionalsemantics for program elements like classes, methods andfields they define. For instance, it may be relevant thatone class inherits from another or that a certain field canonly be accessed locally. For reasons of good readability thecomposition mechanism should be declared together withthe definition of the program element then. One possibilityto achieve this while staying flexible and independent ofkeywords is to use annotations that can be accessed by compositionoperators. Co-op/II does not yet have full supportfor annotations on method and field declarations, but canonly use a few hard-wired ones. To enable the full benefitof annotations, we intend to further extend Co-op/II’s reflectivecapabilities to access annotations in the definition ofbindings.Currently, the only supported condition that can be usedin constraints is whether a named binding is applicable ornot. But sometimes, it is necessary to disable a bindingwhen a certain predicate is satisfied. Consider for examplethe SelectiveFieldAccess composition operator which is supposedto disable the binding that realizes to share fields betweenthe super and the sub class. In our implementationwe had to use a workaround which is to define a binding inSelectiveFieldAccess that is applicable when the sharedFieldBindingshould be ignored and then define a constraint between thesetwo. We plan to improve the expressiveness of conditionalconstraints in Co-op/II.9. REFERENCES[1] L. Bergmans, W. Havinga, and M. Akşit. First-classcompositions–defining and composing object andaspect compositions with first-class operators.Transactions on Aspect-Oriented SoftwareDevelopment, Special issue on Modularity Constructsin Programming Languages, TBD.[2] G. Bracha and G. Lindstrom. Modularity meetsinheritance. In In Proc. International Conference onComputer Languages, pages 282–290. IEEE ComputerSociety, 1992.[3] C. Clifton, G. T. Leavens, C. Chambers, andT. Millstein. Multijava: modular open classes andsymmetric multiple dispatch for java. In Proceedings ofthe 15th ACM SIGPLAN conference onObject-oriented programming, systems, languages, andapplications, OOPSLA ’00, pages 130–145, New York,NY, USA, 2000. ACM.[4] A. J. de Roo, M. F. H. Hendriks, W. K. Havinga,P. E. A. Durr, and L. M. J. Bergmans. Compose*: alanguage- and platform-independent aspect compilerfor composition filters. In K. Mens, M. van den Brand,A. Kuhn, H. Kienle, and R. Wuyts, editors, FirstInternational Workshop on Academic SoftwareDevelopment Tools and Techniques, Cyprus, July2008. No publisher.[5] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.Design Patterns: Elements of ReusableObject-Oriented Software. Addison Wesley, Reading,Massachusetts, 1994.[6] W. K. Havinga, L. M. J. Bergmans, and M. Akşit. Amodel for composable composition operators:Expressing object and aspect compositions withfirst-class operators. In Proceedings of AOSD, pages145–156. ACM, March 2010.[7] W. K. Havinga, C. M. Bockisch, and L. M. J.Bergmans. A case for custom, composable compositionoperators. In Proceedings of the 1st InternationalWorkshop on Composition: Objects, Aspects,Components, Services and Product Lines, Rennes,France, volume 564 of Workshop Proceedings, pages45–50. CEUR-WS, March 2010.[8] K. Ostermann and M. Mezini. Object-orientedcomposition untangled. In Proc. OOPSLA ’01 Conf.Object Oriented Programming Systems Languages andApplications, pages 283–299. ACM Press, 2001.[9] R. Ramachandran, D. J. Pearce, and I. Welch.AspectJ for multilevel security. In Y. Coady, D. H.Lorenz, O. Spinczyk, and E. Wohlstadter, editors,Proceedings of the Fifth AOSD Workshop on Aspects,Components, and Patterns for Infrastructure Software,pages 13–17, Bonn, Germany, Mar. 20 2006. Publishedas University of Virginia Computer Science TechnicalReport CS–2006–01.[10] B. G. Ryder, M. L. Soffa, and M. Burnett. The impactof software engineering research on modernprogamming languages. ACM Transactions onSoftware Engineering and Methodology, 14:431–477,October 2005.[11] A. Taivalsaari. On the notion of inheritance. ACMComput. Surv., 28(3):438–479,1996.[12] É. Tanter. Aspects of composition in the Reflex AOPkernel. In Proceedings of the 5th InternationalSymposium on Software Composition (SC 2006),volume 4089 of lncs, pages 98–113, Vienna, Austria,Mar. 2006. Springer-Verlag.[13] É. Tanter and J. Fabry. Supporting composition ofstructural aspects in an AOP kernel. Journal ofUniversal Computer Science, 15(3):620–647,2009.[14] D. Wagelaar and L. Bergmans. Using a concept-basedapproach to aspect-oriented software design. InM. Glandrup, P. Tarr, S. Clarke, and F. Akkawi,editors, Workshop on Aspect Oriented Design —Identifying, Separating and Verifying Concerns in theDesign (AOSD-2002), Mar. 2002.[15] Xerox Corporation. The AspectJ programming guide.http://www.eclipse.org/aspectj/doc/released/progguide,2003.
Composing heterogeneous software with styleStephen Kell ∗Computer Laboratory, University of CambridgeStephen.Kell@cl.cam.ac.ukABSTRACTTools for composing software impose homogeneity requirementson what is composed—that modules must share alanguage, target the same libraries, or share other conventions.This inhibits cross-language and cross-infrastructurecomposition. We observe that a unifying representation ofsoftware turns heterogeneity of components into a matterof styles: recurring interface patterns that cross-cut largenumbers of codebases. We sketch a rule-based language forcapturing styles independently of composition context, anddescribe how it applies in two example scenarios.1. INTRODUCTIONOur ability to build software compositionally from unmodifiedcomponents is limited by two problems. Firstly,tools (such as compilers and linkers) require that composedmodules be plug-compatible—their interfaces match “in thesmall”. Where this does not hold, compositions are achievedonly by laborious glue coding or invasive editing. Secondly,they must be homogeneous—functionally compatible modulescan not be composed if they are written in different languages,using different interface conventions, different codingstyles, or different support libraries. This severely limitsthe space of possible compositions. Considerable prior workhas targeted the first problem [7, 15–17, 21, 23]. However,the second has received only narrow special-case treatments(such as pairwise interoperation between languages [3, 4, 6]or realisations of procedure- or message-based interaction[2, 9]) or clean-slate approaches [10].This paper outlines ongoing work on an approach to heterogeneouscomposition, based on interface styles. Its keyinsight is that given an appropriate unifying medium—anintermediate representation capturing diverse components—heterogeneity is reduced to differing patterns of usage withinthat medium, which we call stylistic variation. A style is∗ The author is now primarily affiliated with the Departmentof Computer Science, University of Oxford. The detailsshown remain valid.Permission to make digital or hard copies of all or part of this workforpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopiesbear 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, UK.Copyright 2011 ACM 978-1-4503-0892-2/11/07 ...$10.00.any recurring convention used to realise some programmaticconcern; example concerns include error-handling, functiondispatch, representation of common data types (lists, sets,strings, etc.), memory management, and so on. Styles are bydefinition cross-cutting: they recur across large populationsof components (i.e. the components that are homogeneouswith respect to the style) which may be dissimilar otherwise.By allowing programmers to describe styles abstractly, independentof composition context, we can re-use this descriptiveeffort to simplify large numbers of composition tasks.In our approach, styles are described by the programmerusing high-level rules. From such descriptions, guided by aset of input components annotated with references to theirstyles, a glue code generator can compose heterogeneoussoftware essentially by inserting code to “undo” one stylisticconcretion and “replay” a different one at the boundarybetween modules. Our approach is black-box, meaningitissensitive only to an interface abstraction of components. Itis also incrementally adoptable, inthatitappliestoalargepopulation of existing components.Specifically, we present the following contributions:• we characterise the phenomenon of stylistic variation,by identifying a selection of stylistic concerns and somefamiliar concretions of each;• we sketch a notation for describing styles, as an extensionto the Cake linking language [16], and present twoexamples of composition tasks handled using styles;• we discuss some semantic and practical questions arising,and outline possible future directions.We begin with a simple example of stylistic variation.2. CHARACTERISING STYLESSuppose two programmers independently develop a simplecomponent for counting the lines, words and characters in afile. Fig. 1 shows what they might write. The componentsare abstractly equivalent, but concretely different. Our goalis to capture these concrete differences programmatically,hence allowing a tool to abstract them away, so that codetargetting one of them could instead compose with the other.We can observe some dimensions of stylistic variation ataglance. Outputparametershavebeenencodeddifferently,as have character strings. One component provides an explicitresource management API, implicitly also handling initializationand finalization, whereas the other provides onlyexplicit initialization. Naming conventions for multi-word
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: • The keywords final in Java, con
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 and 26: CG Template 1CG Template 2...CodeSl
Page 27 and 28: Open, extensible composition models
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?