Model Transformations in Converge. In: 2Nd Workshop in Software Model Engineering (Wisme 2003), October 2003, San Francisco
Total Page:16
File Type:pdf, Size:1020Kb
Middlesex University Research Repository An open access repository of Middlesex University research http://eprints.mdx.ac.uk Tratt, Laurence and Clark, Tony (2003) Model transformations in converge. In: 2nd Workshop in Software Model Engineering (WiSME 2003), October 2003, San Francisco. [Conference or Workshop Item] This version is available at: https://eprints.mdx.ac.uk/5911/ Copyright: Middlesex University Research Repository makes the University’s research available electronically. Copyright and moral rights to this work are retained by the author and/or other copyright owners unless otherwise stated. The work is supplied on the understanding that any use for commercial gain is strictly forbidden. A copy may be downloaded for personal, non-commercial, research or study without prior permission and without charge. Works, including theses and research projects, may not be reproduced in any format or medium, or extensive quotations taken from them, or their content changed in any way, without first obtaining permission in writing from the copyright holder(s). They may not be sold or exploited commercially in any format or medium without the prior written permission of the copyright holder(s). Full bibliographic details must be given when referring to, or quoting from full items including the author’s name, the title of the work, publication details where relevant (place, publisher, date), pag- ination, and for theses or dissertations the awarding institution, the degree type awarded, and the date of the award. If you believe that any material held in the repository infringes copyright law, please contact the Repository Team at Middlesex University via the following email address: [email protected] The item will be removed from the repository while any claim is being investigated. See also repository copyright: re-use policy: http://eprints.mdx.ac.uk/policies.html#copy Model transformations in Converge Laurence Tratt, Tony Clark King's College London September 8, 2003 Abstract Model transformations are currently the focus of much interest and research due to the OMG's QVT initiative. Current proposals for model transformation lan- guages can be divided into two main camps: those taking a `declarative' approach, and those opting for an `imperative' approach. In this paper we detail an imper- ative, meta-circular, object orientated, pattern matching programming language Converge which is enriched with features pioneered by the Icon programming lan- guage, amongst them: success/failure, generators and goal-directed evaluation. By presenting these features in a language suitable for representing models, we show that we are able to gain some of the advantages of declarative approaches in an imperative setting. 1 Introduction Model transformations are currently the object of much interest and research. The Ob- ject Management Group (OMG), the standards body behind UML, recently published a Request for Proposals (RFP) named Queries Views Transformations (QVT) [OMG02] for model transformations which has bought to light an area of modelling technology that had hitherto been largely ignored. Model transformations are a vital constituent of the realization of the MDA vision [BG02]. Although there has been some discussion of the problem at hand [Bez01´ , dMES02] and some early attempts at tackling the prob- lem [LB98b, LB98a, HJGP99, Gog00, LKM+02], surprisingly little progress has been made in tackling real-world transformations. The authors of this paper are members of the QVT-Partners, have contributed to the QVT-Partners submission to the QVT RFP [QVT03], and have also been co-authors on a follow up paper [ACR+03]. Current QVT submissions, and indeed existing approaches to model transforma- tions in general, can be broadly categorized into two camps: those taking a ‘declara- tive’ approach, and those opting for an ‘imperative’ approach. The terms declarative and imperative can sometimes be rather contentious, and we use them with no small hesitation – they can also be rather crude mechanisms for classifying approaches. With that warning in mind, it is important to realize that in the wider context of programming languages there is a generally accepted consensus as to which of the two approaches most languages adhere to. Crudely put, a language is considered to be imperative if it has side effects and if it forces the programmer to be explicit about the sequence of steps to be taken when it is executed; languages that are side effect free and do not force the programmer to be explicit about the execution sequence are considered to be declarative. Declarative languages aim, to varying degrees, to allow the programmer 1 to express the desired result of an operation without having to express the complete low-level machinery necessary to achieve that result. Although this is a noble goal, declarative solutions can suffer from several problems in practice, including that: pro- grams written in them may not always be executable; some real world problems are very difficult to express satisfactorily (many people are aware of the problems that input/output creates for most functional languages). Partially due to these problems, imperative languages continue to dominate the computing world. The Icon programming language [GG96a] is a SNOBOL derivative, which contains several unique constructs which make it particularly well suited to the job of analyzing and transforming strings. Icon is notable in that whilst a cursory glance would suggest that it is a fairly standard imperative programming language, a closer examination re- veals that the fundamental building blocks it is based on on are significantly different than those found in most other programming languages. The most important features for our purposes are the concepts of success and failure, generators and goal directed evaluation. Although Icon is an imperative language, and can be used in a way that is largely similar to other imperative languages, these features allow a programmer to express some very complex tasks in a manner that can be viewed as being more reminiscent of declarative approaches than traditional imperative approaches. The fundamental idea behind our work has been to take the parts of Icon that make it well suited to string transformation and integrate that into an object orientated view of the world, particularly one that is amenable to manipulating models. The initial results of our work have resulted in a prototype of a language named Converge. The high level design goals of Converge are to merge the following elements into one whole: object pattern matching as found in the QVT-Partners QVT submission [QVT03]; the syntactic elegance and dynamic nature of Python [vR01]; the meta-circularity of ObjVLisp [BC87, Coi87]; and the features of Icon outlined above. Although the design and implementation of Converge are still in their relatively early stages, most of the fundamental concepts are in place and demonstrate that the approach is one that has much potential. 2 Model transformations Put simply, the process of model transformation involves two models, one of which is a changed version of the other. In the context of Converge we are chiefly interested in transformation implementations – transformations which actually alter a model – as opposed to transformation specifications which check the result of a transformation for correctness. Transformations are increasingly recognized as a specialized, but highly important, task for which specialist tools, techniques and methodologies need to be developed. The QVT RFP has given momentum to the until now rather hesitant work on model transformations, and thus any current model transformation work needs to be related to the QVT process. As the authors of this paper are members of the QVT-Partners, it is hardly surprising that Converge shares a number of features in common with that submission. 2 3 Converge The high level design goals of Converge are to merge the following elements into one whole: • Object pattern matching as found in the QVT-Partners QVT submission. • The syntactic elegance and dynamic nature of Python. Whilst keeping this goal in mind, we have no desire to include wholesale some of Python’s more obvious warts including: we replace Python’s clunky scop- ing rules1 with full statically determined lexical closures; we do not emulate Python’s notion of bound and unbound class methods, which require unpleasant user-visible trickery to maintain in a meta-circular context. • The meta-circularity of ObjVLisp. ObjVLisp has an elegant system whereby everything in a system is an object, and every object is an instance of a class (see section ??) meaning that not only can metaclasses be created, but metaclasses are an equal part of the entire system. This allows powerful new abstractions to be built up by users. • The salient features of Icon outlined above. In this section, we first address some relevant background information required to understand the rest of the paper; then we describe features of Converge that are inher- ited from Icon; we then briefly cover the meta-circular nature of Converge influenced by ObjVLisp; and finally outline object pattern matching. 3.1 Icon The Icon programming language, whose chief designer was Ralph Griswold, is a de- scendant of the SNOBOL series of programming languages – whose design team Gris- wold had been a part of – and SNOBOL’s short-lived successor SL5. SNOBOL4 in particular was specifically designed for the task of string manipulation, but an unfortu- nate dichotomy between pattern matching and the rest of the language, and the more general problems encountered when trying to use it for more general programming is- sues ensured that, whilst successful, it never achieved mass acceptance; SL5 suffered from almost the opposite problem by having an over-generalized and unwieldy proce- dure mechanism. See Griswold and Griswold [GG93] for an insight into the process leading to Icon’s conception. Since programs rarely manipulate strings in isolation, post-SL5 Griswold had as his aim to build a language which whilst being aimed at non-numeric manipulation also was usable as a general programming language.