Adaptive Component-Based Framework for Supporting Language Engineering Candidate: Frédéric Fondement Advisor: Thomas Baar Research Plan proposal for a Ph. D. Thesis July 2005 École Polytechnique Fédérale de Lausanne (EPFL) Laboratoire de Génie Logiciel

I. Motivation Language construction is playing a primary role in software engineering since the generalization of compilers. On the one hand, it permits to raise the level of abstraction at which the stakeholders of a software project work. On the other hand, it helps a lot in defining steps of software lifecycle, by stating the notations of the artifacts produced by each step. Indeed, language abstraction has dramatically improved the achievable complexity of software over the last forty years, moving from ten thousand to ten million lines of code nowadays [1]. Nevertheless, language engineering generally a task that needs to be realized by specialists. Though language definition is mainly a concern of domain specialists, language engineers are still responsible for creating and tooling languages. Indeed, to create and tool a language, it is necessary to define the abstract syntax, and implement the tools to create / manipulate it, that is editors, interpreters, etc., which are non-trivial and time-consuming activities. Problems also appear when attempting to define either a “dialect” (i.e. a variant) of a language (mutability issue), or to compose it in a larger language with similar concepts (reusability issue). One could imagine that if reusability and mutability issues could be solved in a comprehensive way, then domain specialists can define themselves their Domain Specific Language (DSL) by relying on other existing languages, reusing and extending related tool support. Easing the task of creating DSLs would help in preventing abstraction pertinence issues [2], thus raising productivity [3]. Methodologists would also be provided a mean to specify more easily the languages involved, that could in turn be formally adapted and assembled by project architects in the context of a specific project (see [4] for more details). An illustration for the lack of adaptability problem is the Xion language tool implementation [5]. Xion is an action language for UML class diagrams. It is inspired by Java for control flow and side effect features, and by the Object Constraint Language (OCL) [6] for navigation capabilities within UML class diagrams. Because of the lack of reusability of language artifacts, neither parsers, abstract syntaxes, nor compilers for OCL or Java could be reused. Indeed, the Xion editor and compiler chain had to be created from scratch. Problems also appear when it comes to adaptability: even though Xion artefacts would have been defined on top of OCL artefacts, it would not be possible to reuse the Xion language to target another object oriented formalism than UML class diagrams. Indeed, OCL is affixed to UML, though one could imaging using it in other contexts, like Entity / Relationship diagrams, or database schemas. Here, we propose to study the techniques for realizing language tool support by assembling and composing so called language components, as promoted by Component Based Software Engineering (CBSE) [7]. Examples of language components are a parser or an interpreter for a given language. We also aim at investigating how those language components may be tailored to particular cases, so that one can adapt one or more language components to a particular use or dialect. The overall principle should be as comprehensive as possible, for non language specialists to be able to construct a language framework for a new or extended language by composing and adapting existing language components.

II. State of the Art A. Model-Based Engineering Model Driven Engineering [8] and other metamodel-based approaches [9][10] offer the possibility (1) to formally define methodologies, (2) to develop systems at any level of abstraction, and (3) to organize and automate the testing and validation activities. Moreover, this technique states that any artefact should be expressed by models, which are both human readable and machine understandable. Models,

1/5

Adaptive Component-Based Framework for Supporting Language Engineering

depending on what they represent, can reside at any level of abstraction, and can be restricted to address only certain aspects of the system. Since they are all machine understandable, several collaborative tools can automate (at least partially) a certain number of tasks, such as model refactorings, model refinements, test case generation, or model to code generation. As a consequence, the process of developing systems becomes iterative, refining abstract models to more concrete ones, and in the end, automatically generating and deploying the complete code. A first important technique for model-based engineering is metamodeling [11], which allows one to define precisely a class of models. Metamodeling formalizes a modeling language by specifying its abstract syntax. Different standards (like [12] or [13]) and tools (like [14]) support metamodeling. Some tools, which are called model repositories, store the possible models. A model repository can be compared to a database system, which stores data according to schemas: a model is stored according to its metamodel. Nevertheless, a precise specification for transforming a text to a model (as performed by a parser), or to edit graphically a model depending on user interactions (as performed by a graphical editor) are still research issues. A second technique is model transformation [15]. This technique allows one to formally define relationships between models by the knowledge of implied metamodels. This technique makes it possible to specify the refinements from an abstract model to a more platform specific one, i.e. a less abstract model. According to [15], an ideal transformation interpreter would perform both forward and reverse transformations. Such bidirectional transformations would enforce model synchronization. On one hand, a change to the abstract model is propagated to the refined models. On the other hand, a change to the refined model would impact automatically its abstract model. Moreover, model transformation specifications give a mean to verify the consistence between such related models, at any moment during the system life cycle. Although some tools already support (mono directional) model transformation (like [17]), a comprehensive formalism for specifying a model transformation is still a research issue.

B. Component-Based Software Engineering The purpose of Component-Based Software Engineering (CBSE) [7] is to produce reusable pieces of software, to be composed and assembled together. Software components are inspired by electronics where reusable pieces of electronic circuits, which are shipped as integrated circuits, can be composed and assembled together through communication interfaces. As electronic components, software components must make explicit their interface, that is their communication gates. A communication gate can be defined using contracts [18], stating what are the available services, and what are the data structures of the results (provided interfaces). It is also necessary to declare what the component expects from the environment to be able to function properly, in terms of services and data structure (required interfaces). Declaring these contracts is mandatory for a component, but does not specify its actual implementation, even though a correct behavior may be inferred directly from its contract; the only requirement is that the provided interfaces are realized in case of the environment actually supplies the required interface. This basically means that a component participating in a system may be replaced by another one without affecting the overall behavior, provided the interfaces are compatible. For instance, a component may be able to replace any component with an equivalent or weaker contract. This implies for instance that a component may be improved in a new version with corrections, more services, and improved performance, and then deployed again in any system where it is used. In that specific scenario, the component is not aware of the systems in which it is deployed, nor those systems are aware that the component has actually changed. To build a component framework, component instances are connected to each other by putting face to face provided and required interfaces, under the condition that for each required interface is actually connected to a provided interface with an equivalent or stronger contract. An interesting property is that a component may be built out of a component framework. Such a composite component exposes provided interfaces that have to be matched for each of them by a provided interface of a composed component instance, and required interfaces that can be matched by provided interfaces of component instances in the framework.

2/5

Adaptive Component-Based Framework for Supporting Language Engineering

III.Research Plan The overall goal of the research is to be able to create language tool support frameworks by assembling and adapting so called language components. Such framework would describe a modeling architecture putting in correspondence model providers, such as parsers, editors, or repositories, with model consumers, such as model transformations, in turn providing new kinds of models, interpreters or code generators. Here, we have made here a clear separation between languages as defined by their metamodel, and language components, that offer some behavior related to models, i.e. instances of metamodel as language sentences.

Subtask 1 - Language Component Kinds and Contracts Purpose: This subpart aims at exploring how language components can be specified in terms of contracts. It is important to find the list of possible kinds of language components, and for each kind, to find a formalism for expressing the behavior realized by such component. Approach: A language component framework may be composed of a variety of components of different kinds. Examples for such kinds are parser, graphical editor, compilers, and interpreters. We need to draw up a list of component kinds. For each one of these kinds, we want to find an appropriate formalism that makes explicit the behavior of the component as a contract. Ideally, given an abstract syntax of the language and a definition of the contract, an automatic tool would be able to simulate the behavior of a component realizing that contract for that specific language. As we place ourselves in the context of model driven engineering, both the abstract syntax of the language and the definition of the contracts should be formalized by a metamodel. An existing example for a simple language component kind is model repositories. A model repository is a tool that stores a model according to its metamodel. A contract for such kind of language component can be merely the metamodel of the language. Another kind of component is model transformation. A precise specification formalism is under standardization [16] and this work intends to reuse the outcome of that standardization process. Nevertheless, model transformations are language components that can legitimately take part in a language framework, and can be paid consideration for realizing other kinds of components, like for compilers. Results: • Identification of the kinds of language components that can take part in a language tool support framework; an example is the graphical editor. • For each identified kind, a metamodel of the contract describing properly the behavior of a component; part of that result is a metamodel for formalizing graphical syntax. • For each contract metamodel, a simulation tool; part of that result is a graphical model editor taking advantage of both the model to represent, and the contract describing the graphical syntax.

Subtask 2 - Language Components Adaptability Purpose: A limitation of component oriented software engineering is that components have to be assembled by providing to each required interface a provided interface with a compatible contract. Indeed, it often appears that similar contracts are actually incompatible. The reason, which we qualify as the syntax defect, can be that despite manipulated concepts are almost the same, they are not expressed by the same constructs. Another reason, which we qualify as the semantic defect, can be that the contract is almost, yet not completely, fulfilled. The purpose of that subtask is to find some solution to overcome these two defects. Approach: To solve the syntactic defect, a syntactic adaptation has to be completed. This role can be played by a new kind of component that can participate in the language framework. Such component, which we call adapter, make correspond two syntactically incompatible interfaces. The required one defines a provided interface of the adapter, and the provided one defines a required interface of the adapter. If such an adapter component could be described in a simple way, then component framework would gain much in reusability: components do not need to care about the environment, thus they can concentrate on the concepts in which they are really interested. For realizing such adaptor specification, we intend to study an approach based on refinement: the provided interface of the adaptor could be refined to act as a proxy for the required one: manipulations performed on the provided interface are actually converted to manipulations on the required interfaces. Solving the semantic defect boils down to solve the mutability of components: one can enhance existing concepts or even add new ones in the abstract syntax, and mutate the components to take those enhancements into account. Doing so

3/5

Adaptive Component-Based Framework for Supporting Language Engineering

requires to have the knowledge of what is the abstract syntax, and what do the components (that need to be mutated) do; actually, it is up to the contract of the components to be precise enough to acquire such knowledge. If enhancing the abstract syntax can be performed by a refinement process [20], mutating a component’s contract is not so obvious. We intend to study refinement and crosscutting concern integration techniques like Aspect-Oriented Programming [21]. Mutation of a component should not only impact the contract, but also the implementation. However, we do not plan to solve that kind of problem, and we will restrict ourselves to contracts mutability, as a (mutated) contract should be sufficient to describe a behavior that can be simulated. Results: • A comprehensive formalism together with tool support for specifying an adaptor component. • An evaluation of techniques such as refinement or aspect-oriented programming for adaptability of components; some guidelines for mutating language components. • Tool support for mutability concerns such as a refinement tool and an aspect weaver.

Subtask 3 - Language Case Study Purpose: This subtask aims at validating the concepts found in the other subtasks by implementing a concrete language framework. Approach: An example of language that can be reused and tuned in various ways including the related language components, is the Object Constraint Language that we propose to tool using a language component framework as identified in the “Language Component Kinds and Contracts” subtask. Indeed, the OCL abstract syntax, though it is defined as an extension for the UML abstract syntax, can serve in various contexts. First, it should be possible to reuse a given version of OCL for any version of the UML metamodel. Second, OCL may not be applied only on UML: one can think using OCL in the context of relational databases, or object-oriented programming languages as Java. Moreover, OCLrelated language components could also be mutated to integrate various purposes: one can think integrating new concepts as in the Fondue notation, that reuses OCL for defining operation schemas. Thus, we could validate reusability concepts as identified in the “Language Components Adaptability” subtask. Results: • A language component framework for the OCL language, including most kinds of components as identified by the the “Language Component Kinds and Contracts” subtask, and independent from the extended language. • Adaptation of the OCL framework for the Fondue toolset using tools and abstractions found in the the “Language Components Adaptability” subtask.

IV. Tentative Time Schedule The 1st semester corresponds to the winter semester of 2005. As the “Language Case Study” subtask is

Subtask

1st semester

2nd semester

1

X

X

2 3

X

3rd semester

X

X

X

X

a validation of concepts developed in other subtasks, it will be performed concurrently to them. In the 4th semester, the results will be finalized and the dissertation will be written.

4/5

Adaptive Component-Based Framework for Supporting Language Engineering

V. References [1] J.-M. Jézéquel, Model-driven engineering: Basic principles and challenges, Invited Presentation at Formal Methods for Components and Objects (FMCO'03), Leiden, Netherlands, November 2003. [2] J. Iivari, Why are CASE Tools Not Used?, Communications of the ACM, Vol. 39, No. 10, October 1996. [3] R. B. Kieburtz, L. McKinney, J. M. Bell, J. Hook, A. Kotov, J. Lewis, D. P. Oliva, T. Sheard, I. Smith, L. Walton: A software engineering experiment in software component generation, In Proceedings of the 18th IEEE International Conference on Software Engineering ICSE-18, 1996, pages 542 – 553. [4] F. Fondement, R. Silaghi, Defining Model Driven Engineering Processes, 3rd Workshop in Software Model Engineering (WISME @ UML 2004), UML 2004, Lisbon, Portugal, October 2003. Available as Technical Report IC/2004/94, Swiss Federal Institute of Technology in Lausanne, Switzerland, November 2004. [5] P.-A. Muller, P. Studer, F. Fondement; J. Bézivin: Platform Independent Web Application Modeling and Development with Netsilon, Journal on Software and Systems Modeling (SoSyM), Best papers of the '03 conference, 2005. [6] Object Management Group, UML 2.0 OCL Final Adopted specification, ptc/03-10-14, October 2003. [7] C. Szyperski, “Component Software”, Addison-Wesley Professional; 2nd edition, November 2002. [8] S. Kent, Model Driven Engineering, Integrated Formal Methods: Third International Conference, IFM 2002, Turku, Finland, May 15-17, 2002. LNCS Volume 2335, Springer, 2003, pages 286 – 298. [9] S J. Mellor, A. N. Clark, T. Futagami: Model-Driven Development, IEEE Software, Volume 20, Issue 5, September-October 2003, pages 14 – 18. [10]T. Clark, A Evans, P. Sammut, J. Willans, “Applied Metamodelling, A Foundation for Language Driven Development”, Version 0.1, August 2004. [11]C. Atkinson, T. Kühne, The Role of Metamodeling in MDA, International Workshop in Software Model Engineering (in conjunction with UML’02), Dresden, Germany, October 2002. [12]Object Management Group, Meta Object Facility 2.0 Core Specification, ptc/04-10-15, October 2003. [13]Java Community Process, Java™ Metadata Interface (JMI) Specification, JSR 040, June 2002. [14]Sun, Metadata Repository (MDR), part of the Netbeans project, July 2005. [15]S. Sendall, W. Kozaczynski, Model Transformation: The Heart and Soul of Model-Driven Software Development, IEEE Software, Volume 20, Issue 5, September 2003, pages 42 – 45. [16]Object Management Group, MOF 2.0 Query/Views/Transformations, ptc/03-10-14, October 2003. [17]D. Vojtisek, BasicMTL Realization Guide, Inside the Carroll Research Program and part of the MOTOR project, Technical Report, February 2004. [18]A. Beugnard, J.-M. Jézéquel, N. Plouzeau, D. Watkins, Making Components Contract Aware, Computer, Volume 32, N° 7, July 1999, pages 38 – 45. [19]B. Meyer, “Object-Oriented Software Construction”, Prentice Hall, 2nd edition, March, 2000. [20]E. Ernst, Higher-Order Hierarchies, LNCS Volume 2743, January 2003, pages 303 – 328. [21]G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, J. Irwin, Aspect-oriented programming, Proceedings ECOOP’97, LNCS 1241, Springer, June 1997, pages 220–242.

VI.Research Plan Approval Ph.D. Candidate Frédéric Fondement

Thesis Director Dr. Thomas Baar

Doctoral Program Director Prof. Emre Telatar

5/5