Hugo Brunelière
email: hugo.bruneliere@inria.fr

Jordi Cabot
email: jordi.cabot@inria.fr

Frédéric Jouault Atlanmod

Combining Model-Driven Engineering and Cloud Computing

Service-orientation and model-driven engineering are two of the most dominant software engineering paradigms nowadays. This position paper explores the synergies between them and show how they can benefit from each other. In particular, the paper introduces the notion of Modeling as a Service (MaaS) as a way to provide modeling and model-driven engineering services from the cloud.

Introduction

Model-driven engineering (MDE) is becoming the dominant software engineering paradigm to specify, develop and maintain software systems. In MDE, models are the primary artifact of the engineering process and are used, for instance, to (semi)automatically generate the implementation of the final software system.

At the same time, service-orientation is gaining popularity as the standard way of designing and deploying software applications over the internet, specially for distributed and e-commerce applications. With service-orientation, software is reorganized as a set of interacting services that client applications (e.g. other services) can execute on demand. This is also known as Software as a Service (SaaS).

Therefore, it is just natural that we wonder how both paradigms can be integrated and benefit from each other. In this paper we discuss two different collaboration scenarios between MDE and SaaS: 1 -using MDE for the development of SaaS applications (Section 2) and 2 -using SaaS to deploy modeling services in the cloud (Section 3).

MDE for the cloud

MDE techniques can facilitate and (semi)automate the development of new SaaS applications. Several approaches (see [START_REF] Johnston | A model-driven development approach to creating service-oriented solutions[END_REF], [START_REF] Ortiz | Service-oriented model-driven development: Filling the extra-functional property gap[END_REF], [START_REF] Baïna | Modeldriven web service development[END_REF] and [START_REF] Manolescu | Model-driven design and deployment of service-enabled web applications[END_REF] as relevant examples) have already explored this possibility. Given the set of domain models (i.e. platform-independent models) of the systemto-be (possibly complemented with additional information regarding the system decomposition into a set of services by means of UML profiles or domain-specific languages) model-to-model and model-to-text transformations could be used to generate and deploy the software system as part of a service-oriented architecture (SOA). Unfortunately, there

is not yet a consensus on the right set of models, languages, model transformations and software processes for the model-driven development of SaaS systems.

Morevoer, this just solves a small part of the problem. One of the main challenges SaaS faces to become mainstream is the problem of coping with all existing software, that should now be considered as legacy software (from a cloud point of view). This software needs to be evolved and adapted in order to be able to be executed as a service. This topic has not yet been studied but we believe model-driven reverse engineering techniques (such as our own MoDisco framework [START_REF]MoDisco Toolbox[END_REF], [START_REF] Barbier | MoDisco, a Model-Driven Platform to Support Real Legacy Modernization Use Cases[END_REF]) can help in this matter. These techniques are able to discover and extract software models out of the artifacts of a legacy system. The idea would be to be able to produce the kind of software models needed to reimplement the system under the SaaS paradigm using the methods mentioned above.

MDE in the cloud: Modeling as a Service

We believe cloud computing can bring many benefits to MDE. In this sense, we would like to propose the Modeling as a Service (MaaS) initiative 1 . Similar to SaaS, MaaS would allow the deployment and on-demand execution of modeling and model-driven services over the Internet. We are confident that MaaS will contribute to widen even more the adoption of MDE among software practitioners. In what follows we comment some possible applications of MaaS:

• Creation of collaborative and distributed modeling 1 This acronym has also been independently proposed in the context of the ENVISION project (http://www.envision-project.eu), with the meaning of Models as a Service, as a way to exchange environmental models P r e l i m i n a r y V e r s i o n tools to allow the specification and sharing of software models among team members in real-time.

• Definition of modeling mash-ups as a combination of MDE services from different vendors.

• Availability of model transformation engines in the cloud to provide platform-independent model management services

• Improving scalability of MDE. Models of real-life applications (specially those obtained by reverse engineering of running systems) are usually very large.

Modeling services in the cloud would ensure the scalability of MDE techniques in those scenarios.

• Facilitating Model execution and evolution. Moving code-generation and simulation services to the cloud would facilitate the deployment and evolution of software applications (regardless whether those applications are implemented as SaaS or not) and reduce their time to market. Designers could forget about setting up the infrastructure to compile and deploy the applications and would be able to rely on the cloud for that.

• Solving tool interoperability problems. Exchanging data (and metadata) among MDE tools is one of the major challenges of MDE nowadays. So far, the problem is being addressed by defining bridges among the tools (e.g. [START_REF] Brunelire | Towards Model Driven Tool Interoperability: Bridging Eclipse and Microsoft Modeling Tools[END_REF]) but MaaS would offer a more transparent and global solution to this problem. For instance, bridges could be defined as services automatically executed on demand by other services when incompatibility issues are detected.

• Distributed Global model management. Complex MDE projects involve several models (possibly conforming to different metamodels), model transformations, model injectors and projectors, ... MaaS would facilitate the manipulation of all these modeling artifacts in a distributed environment.

Research on all these topics is in very preliminary stages. The firsts web-based modeling tools (such as Creately2 or Gliffy3 ) have just recently appeared. Some discussions about the benefits of using the cloud as a modeling repository (see the WebUML4 initiative) or as a deployment platform (see the Enterprise Architect5 blog) have also started but no concrete results have been provided and most services in our list have yet to be explored. As far as we know, our initiative would be the first systematic research project on the benefits and challenges of the MaaS approach.

We are confident that the technical challenges to make MaaS a reality can be overcomed by learning from how SaaS has developed. Some parts of SOAs are directly applicable to modeling services but others should be adapted. In particular, we will need to agree on a description language for this kind of services (probably based on a predefined taxonomy/ontology) to facilitate the discovery and composition of services, on a common type systems for those services and to check whether current standards for web service orchestration and choreography can be reused in our context. We also need to develop parallel versions for the most time-consuming model manipulation algorithms (i.e. for transformation, verification,...) in order to benefit from the computing power of the cloud.

Conclusions

This paper has commented on the possible synergies between the model-driven engineering and service-orientation paradigms. Some research challenges that need to be solved in order to make this collaboration possible have also been mentioned. We plan to continue our work by further exploring and addressing these challenges.

http://creately.com/

http://www.gliffy.com/

http://webuml.org/

http://www.theenterprisearchitect.eu/


Hugo Brunelière
email: hugo.bruneliere@inria.fr

Jordi Cabot
email: jordi.cabot@inria.fr

Frédéric Jouault
email: frederic.jouault@inria.fr

Massimo Tisi
email: massimo.tisi@inria.fr

Jean Bévizin Atlanmod

Industrialization of Research Tools: the ATL Case

Keywords: tool, ATL, prototype, industrialization, model-driven

Research groups develop plenty of tools aimed at solving real industrial problems. Unfortunately, most of these tools remain as simple proof-of-concept tools that companies consider too risky to use due to their lack of proper user interface, documentation, completeness, support, etc that companies expect from commercial-quality level tools.

Based on our tool development experience in the AtlanMod research team, specially regarding the evolution of our ATL model transformation tool, we argue in this paper that the best solution for research teams aiming to create high-quality and widely-used tools is to industrialize their research prototypes through a partnership with a technology provider.

Introduction

In software engineering, many research groups work on topics directly linked to (and sometimes also inspired by) real industrial problems. This research activity usually end ups implemented in a tool that serves as proof of concept for the developed techniques.

These tools are technically good and solve real problems but unfortunately most times they are largely ignored by software practitioners. Technical quality is just one of the many factors that companies analyze when deciding whether to take the risk of adopting a new tool. Examples of other factors that influence this decision are: user support, good documentation or usability aspects. The problem is that resources of research groups are very limited and cannot be usually devoted to work on this non-core research activities (also because funding for tool development is not exactly a priority for funding agencies). Because of this, research groups risk missing the opportunity of having a large user base for their tools along with the benefits that this brings to the table (e.g. empirical validation of their research, feedback, visibility, collaboration opportunities and so on). This is specially true in emerging software engineering areas with growing industrial interest but without a dominant tool/s monopolizing the market and where some of our research tools could make a difference.

We believe that Model Driven Engineering (MDE) is one of these areas. MDE is a software engineering paradigm based on the use of models as primary artifacts of all software engineering activities. Many of these activities imply model manipulations, usually implemented as model transformations. Therefore, availability of tools for specifying and executing model transforma-1 P r e l i m i n a r y V e r s i o n tions is crucial. Right now, the most popular1 model transformation language and toolset is ATL (AtlanMod Transformation Language [START_REF] Jouault | Atl: A model transformation tool[END_REF]). Regardless the technical quality of ATL (comparing technical aspects of ATL with respect to other alternative tools, as graph transformation tools [START_REF] Lara | Defining visual notations and their manipulation through meta-modelling and graph transformation[END_REF] or QVT-based tools [START_REF] Omg | MOF 2.0 Query/View/Transformation specification[END_REF] is not the topic of this paper) we believe its non-technical features have been one of the key factors of its success. In this sense, the goal of this paper is present our experience in the development of a longterm sustainable model for ATL and the choices (both at the technical and business model level) we have made during this process. In particular, we will emphasize our industrialization approach for ATL (through a partnership with the technology provider Obeo [START_REF]The Obeo company[END_REF]) that has permitted us to meet the needs of our large user base while at the same time committing our resources only to the research aspects of the language. This business model has proven to be feasible and beneficial both for the company and for ourselves as a research group.

The rest of the paper is structured as follows. The next section introduces the ATL tooling. Section 3 comments on the challenges of developing a commercial-quality level tool while Section 4 and 5 explain our best practices to overcome these challenges at the technical and business model level, respectively. Section 6 generalizes these results to other tools and, finally, Section 7 presents some conclusions and further work.

Overview of ATL

This section provides some background on the history (Section 2.1) and characteristics (Section 2.2) of the ATL model-to-model transformation language [START_REF] Jouault | Atl: A model transformation tool[END_REF] and highlights the complexity of the tool as it stands today 2.3.

History of ATL

ATL is a model-to-model transformation language created by AtlanMod [START_REF]The AtlanMod team[END_REF], a joint research team between INRIA and Ecole des Mines de Nantes. ATL was first developed as part of the Phd Thesis of Frédéric Jouault [START_REF] Jouault | Contribution to the study of model transformation languages[END_REF] started in 2003.

Simultaneously to the definition of the language, a toolset with the same name to specify and execute ATL transformations was also implemented. This allowed the first concrete use of ATL on industrial scenarios that took place in 2004 in the context of the French project CAR-ROLL/MOTOR, in collaboration with CEA and Thales. Then, the development of the language and tooling has continued, mainly as part of two consecutive European integrated projects called MODELWARE (October 2004 -September 2006) and MODELPLEX (September 2006 -February 2010) which provided many concrete industrial use cases of ATL in various and varied contexts. These use cases provided new research challenges that helped us to improve the language.

ATL is integrated in the Eclipse open source community. It joined the Eclipse-Modeling GMT (Generative Modeling Technologies) project in 2004 and then moved to Eclipse-Modeling M2M (Model-to-Model Transformation) project [START_REF]The Eclipse Model-to-Model (M2M) project[END_REF] in 2006. This was the effective recognition of ATL as one of the de-facto modeling standards in Eclipse. We believe this integration in the Eclipse foundation has contributed a lot to the development of the community and of the tool in general.

Finally, as we will explain in the next sections, the ATL ecosystem and the user community became too large to manage only with the resources available in the AtlanMod team. Therefore, in 2007, it was decided to start a collaboration with the Obeo company with the purpose of industrializing ATL. This situation is still going on today and has proved to be very beneficial for both AtlanMod and Obeo.

Transforming models with ATL

ATL is a model-to-model (M2M) transformation language. M2M transformations specify the production of target models from a number of source models. ATL enables developers to define how source model elements must be matched and navigated in order to create and initialize the target model elements. Roughly speaking, an ATL transformation is defined as a set of declarative rules. Each rule matches a subset of the source model and creates an excerpt of the target model. Pattern matching conditions are expressed in the OCL language [START_REF] Omg | UML 2.0 Object Constraint Language specification[END_REF].

Source and target models can be instance of different metamodels. A simple ATL transformation Mt (see Fig. 1 transforms a model Ma, which conforms to a metamodel MMa, into a model Mb, conforming to a metamodel MMb. Since in MDE everything should be considered, as far as possible, as a model, Mt itself is defined as a model conforming to the ATL model transformation metamodel MMt. All three metamodels conform to a metametamodel MMM such as MOF or Ecore. As an example, Figure 2 shows an excerpt of the classic ClassToRelational model-to-model transformation example. The objective of this transformation is to transform a class diagram into a relational database schema, with the corresponding tables, columns, etc. In this example, the source metamodel is Class and the target metamodel is Relational. The actual transformation defines several rules (as Class2Table and DataType2Type) defining the mappings between the concepts from the two metamodels, and one helper method (helpers factorize ATL code that can be called from different points of an ATL transformation) navigating the input model to retrieve some data needed during the mappings.

Fig. 2 shows part of the ATL Perspective, with the Project Explorer presenting the different resources involved in the transformation, an excerpt of the ATL transformation displayed using the ATL Editor and the Outline of the transformation displaying all its important information. 3

P r e l i m i n a r y V e r s i o n

Current status: the ATL project

More than a simple model transformation language, ATL has evolved into is a full Eclipes project [START_REF]The Eclipse ATL project[END_REF] directly under the umbrella of the Eclipse Modeling top-level project As an Eclipse project, ATL proposes to the community a complete Eclipse IDE (Integrated Development Environment) coming along with the ATL language, core components and many different kinds of resources (see Figure 3). The ATL project is implemented as a set of specific Eclipse plug-ins and features. ATL has a dedicated Eclipse perspective, its own project nature and builders (and corresponding creation wizards) for ATL projects and files. An editor with extended capabilities (syntax highlighting, runtime parsing, compilation and error detection, code completion, etc) and corresponding outline, a debugger, profiler, launcher and ATL Ant tasks have also been implemented.

Apart from the regular plug-in downloads that can be get from the various update sites the project offers a large range of online information: conceptual overview, user guide, developer guide, technical specifications, etc. Many training resources like simple examples, tutorials or complete use cases are also available. Moreover, the project also provides a library of more than one hundred open source model-to-model transformations, all written in ATL and developed by various contributors, concerning many different metamodels and domains. These transformations can of course be taken as examples, but also reused as is or refined/extended for specific transformation scenarios.

Besides this, the ATL community is continuously expanding. There are already several external tools using ATL as their standard model-to-model transformation technology and, in addition 4 P r e l i m i n a r y V e r s i o n

Challenges in the Development of a Commercial-Quality ATL

As ATL was growing into the nowadays complex ecosystem (see previous section) it was clear that ATL had the chance to become the reference model-transformation solution for companies starting to adopt MDE as their development paradigm. As a research group, this was very appealing since it would allow us, among many other benefits, to: 1 -Empirically validate our transformation language and, in general, our research ideas; 2 -to provide good on-the-field experimental data; and 3 -to increase the AtlanMod team visibility, increasing the number of companies/groups that could discover (and become users of) our other works in the MDE field and opening opportunities for future collaborations (e.g. technology transfer contracts or joint participation in international projects). However, we quickly realize that it would be very difficult to maintain all the components of the ATL project and give proper support to users only with the resources available in the team. 5

P r e l i m i n a r y V e r s i o n

Furthermore, focusing on providing a good technical solution would not be enough to keep and expand our user base, for potential users (specially companies) technical quality is only one of the many aspects they take into account when selecting a tool. ATL users started to ask for:

• better user support (e.g. responsiveness to questions, bugs and feature requests)

• up-to-date and complete tool documentation

• good user experience (ergonomy)

• long-term perspectives for the tool

• frequent upgrades and interoperability with the latest versions of other common used tools

• extensibility, adaptability, and all the other typical -ities

• backward compatibility (which many times is difficult to combine with innovative research)

In fact, we agree that all these aspects are important (as first users of the tool we would also benefit from them, e.g. when hiring a new team member a proper documentation set would ease his/her integration in the team activities) and they have been always in the wish-list of ATL though hardly ever made it to the actual to-do list. The main reason is that the low availability of funding for pure tool development forces us (and, in general, all research groups) to focus our resources on the most innovative and research aspects of ATL neglecting all these other issues. This is a direct consequence of the fact that most (all?) government agencies evaluate research groups (and their members individually) exclusively based on the number of papers published by the group, ignoring the impact in the community of the tools developed by them. This makes extremely difficult to convince young researchers pursuing a permanent position to dedicate time to any task that does not immediately and directly lead to new research results.

To overcome this situation, we have put in practice two kinds of strategies during the development of ATL. First, the design of the tool itself simplifies some of these problematic aspects and, more importantly, tries to facilitate the collaboration and technological transfer among all external actors contributing to the ATL development. The second strategy deals with the problem of convincing external people to contribute to ATL. In fact, given the open source license 2 of ATL, one could have the (naive) initial assumption that it would be easy to find external contributors ready to jump in and start working on all aspects a research group cannot cover. However, this assumption fails because few projects are succesful involving external contributors [START_REF] Krishnamurthy | Cave or community? an empirical examination of 100 mature open source projects[END_REF] and most times, these external users also prefer to work on the most challenging tool features and not, for instance, write documentation or improve the graphical user interface. For instance, many important ATL contributors are members of other research groups that extend or improve ATL as part of their research interests. 3 Therefore, we realized that, apart from having a good tool design, we needed to define a business model for ATL to guarantee a continuous influx of resources to satisfy the requests of our users while allowing us to keep focusing on the core research aspects of the tool. Section 4 and Section 5 elaborate on these two kind of strategies. ATL tool design has been influenced by the principles of modularity, interoperability and use of standard (de facto) technologies as a way of facilitating contributions from independent actors taking part in the ATL development. Apart from this, becoming intensive users of your own tool is also a best practice to test if the previous design priciples have been properly followed.

Modularity

The ATL framework has a modular structure based on the extension mechanism of the Eclipse platform [START_REF]Eclipse Helios Simultaneous Release[END_REF], that in turn is built upon the OSGi open modular system. The core modules of ATL are shown in Figure 4. These modules are in charge of the operations that lead to the transformation execution: code parsing and static checking, compilation and bytecode interpretation. The first component is the ATL parser (i.e. the injector in the figure) which takes an ATL source file as input and produces a model that conforms to the ATL metamodel as output plus a problem model storing all errors detected in the code. This error information is then used by the ATL editor to display the corresponding error markers in the ATL source file. The second component is the ATL compiler in charge of converting the ATL model into bytecode (ASM format) interpretable by the ATL Virtual Machine (VM). It has been implemented using ACG, a compiler-oriented DSL [START_REF]ATL VM Code Generator[END_REF]. The last core component, the ATL VM, takes the compiled transformation and actually executes it on the specified input model(s) to generate as a result the output one(s). Additional ATL modules are implemented on top of these core ones to provide the main functionalities of the ATL development environment (e.g., editor, debugger, profiler, launcher). Communicaton between the modules is done thanks to the standard Eclipse extension interfaces. These same interfaces can be used by external developers wanting to make use of ATL in their own Eclipse plug-ins (e.g., AMW [START_REF] Del Fabro | AMW: a generic model weaver[END_REF]).

This modularization of the ATL core allows for a clear separation of concerns among the basic components in charge of the transformation processing. This decoupling has proven to be a valuable asset for collaborative work over the ATL core. For instance, it is common for independent research groups to locate a research problem in only one of these components. Thanks 7 P r e l i m i n a r y V e r s i o n

to the ATL modularization the group only needs to get familiar with a limited set of technologies (e.g. ACG for the compiler) and can provide an updated interchangeable version of the module addressing that specific research issue. Examples of this are the optimization of the collection handling approach of ATL by updating only the virtual machine [START_REF] Cuadrado | A proposal to improve performance of ATL collections[END_REF] or the development of an incremental execution mode for ATL by changing only the ATL compiler [START_REF] Jouault | Towards Incremental Execution of ATL Transformations[END_REF]. The modularization of ATL has shown its importance in several projects during the last years. As a further step in this direction, we plan to introduce a new fine-grained extension system for the ATL core components by defining a new set of extension-points in the core, i.e. of functionalities that can be delegated to externally provided plug-ins.

Standard technologies

An important driver in the success of ATL has been the selection of the right core technologies for grounding the tool. The search for an open framework, supported by a solid open-source community, and that could become the de-facto standard platform for open software engineering tools, lead us to choose the Eclipse platform. The growing popularity of Eclipse and the increasing number of tools migrating to this platform proves our decision right and increases the opportunities of collaborations between ATL and the other Eclipse projects.

A first benefit of integrating ATL in Eclipse is that Eclipse relieves the ATL project from implementing most of the components of the IDE. The ATL perspective reuses many of the standard IDE components provided by Eclipse and adapts them to the specific needs of ATL. Eclipse also provides an extensibility mechanism that facilitates the definition of ATL extensions. Eclipse plug-ins can define extension-points. An extension point indicates that the plug-in is able to delegate that specific functionality to a different plug-in. Extension-points can be answered by extensions, that implement an interface and descriptor matching the extension-point. Availability of a standard extension mechanism is a key factor in enabling the creation of re-usable components from a complex and heterogeneous community.

Finally, the success of a model transformation technology like ATL has necessarily to rely on the success of the underlying modeling framework it uses (i.e. if models to be used as input/output of ATL transformations had to be conformant to a modeling framework nobody uses then, obviously, few people would use ATL). While the modular architecture of ATL favors interoperability and adaptation to different frameworks (see next subsection), we decided to privilege 4the Eclipse Modeling Framework (EMF) since it soon appeared that among several possible alternatives, EMF stood out as the de facto standard solution for model handling. The fact that today most model-based tools in Eclipse work with EMF facilitates the selection of ATL as a model transformation language for their model manipulation activities.

Interoperability

While the early choice of Eclipse and EMF has certainly influenced the success of ATL, the design of its architecture has followed the principle of maximum independence from specific technologies so that we can change these technological choices in the future. For instance, as a transformation language, ATL should be independent on the particular way a model is represented and handled in the modeling environment.

P r e l i m i n a r y V e r s i o n

On the one hand, this criterion guarantees that the longevity of ATL will not be influenced by a particular technology (e.g., EMF) going out of fashion. This is particularly important in an industrial context, where the preservation of investments is a central requirement. On the other hand this independence enables a straightforward path for exporting ATL to other modeling environments (e.g., Microsoft DSL Tools [START_REF]Microsoft Domain-Specific Language (DSL) Tools[END_REF]), with the opportunity of remarkably expand the user base.

As technical solution for remaining independent from the modeling layer we introduced the notion of virtual machine to execute the ATL compiled bytecode. The ATL Virtual Machine is an abstract computing machine, associated with its own instruction set and specialized in model manipulation. Within the virtual machine, an intermediate component called Model Handler Abstraction Layer deals with the specifics of the modeling layer. This component translates the instructions of the VM for model manipulation into instructions for a specific model handler. By implementing an ad-hoc model handler it is possible to use the same VM on top of various model management systems (e.g., Eclipse EMF, Netbeans MDR, Microsoft DSL Tools) [START_REF] Bruneliere | Towards model driven tool interoperability: Bridging eclipse and microsoft modeling tools[END_REF].

Moreover, porting the VM itself to other runtime environments (e.g. from Java to .NET) opens the door to immediately execute ATL transformations in them since any compiled ATL transformation can be indifferently executed on all implementations of the ATL VM that conform to the provided specification, independently of the underlying technology [START_REF] Bruneliere | Towards model driven tool interoperability: Bridging eclipse and microsoft modeling tools[END_REF].

Eating your own dog food

We believe it is important that research groups are the first users of the tool and that the tool is bootstrapped when possible. For instance, the ATL compiler towards ASM bytecode is written in the ACG DSL. The ACG compiler is bootstrapped, being itself written in ACG and being parsed, compiled towards ASM and executed using the same technology (the TCS parser, ACG compiler, ASM virtual machine) used to parse user defined ATL transformations. In the same way the execution of ATL transformations is partially performed using other ATL transformations (e.g. to generate the problem model).

Apart from being a non-trivial test for the tool, the main benefit of this is that any improvement on the tool components improve not only the user-defined transformations but also the ATL engine itself.

The ATL Solution: Business Model

The software engineering best-practices that have been followed since the first years enabled, in a first phase, the construction of an initial open-source community around the tool under the guidance of the research group AtlanMod. However, as argued in Section 3, once the user base started to grow and the ATL project became more complex this was not enough to guarantee a durable and expanding environment for ATL. A novel business model was required, to coordinate needs and efforts of the actors operating around ATL.

In 2007, the industrialization process for ATL started. AtlanMod partnered with Obeo [START_REF]The Obeo company[END_REF] to ensure the existence of an open source but commercial-quality version of ATL. As part of this agreement, Obeo started committing resources on the non-core aspects of ATL (the amount of resources is more or less equivalent to the ones AtlanMod devotes to ATL research topics).

From the point of view of the research group, the main goal of the agreement is allowing AtlanMod to focus its resources on new research activities, and letting Obeo take over traditional software development and maintenance tasks, including performance and usability improvements, bug fixing and user support. Thanks to this agreement, ATL technology reaches an 9

P r e l i m i n a r y V e r s i o n industrial quality, becoming a very attractive tool for company users and a stable base for new research directions. Obeo, on the other hand, gets to strenghten its presence and visibility within the Eclipse community and among industries using its open-source tecnologies. This strategic positioning is used to create a network of key partner companies that help to expand the Obeo market. As part of the agreement, Obeo also becomes the lead ATL training company (AtlanMod redirects to Obeo all ATL-specific course requests coming from companies) and can deliver adapted versions of ATL to specific companies with special needs. Moreover, ATL complements well the other MDE technologies in the the Obeo offering (that already include, for instance, the Acceleo tool for model-to-text transformations) and it is already been used as a key component in Obeo's new tool releases. This in-house development of ATL and the privileged relationship with the creators and lead research contributors of ATL (ourselves) give Obeo a competitive advantage over other companies that also propose products based on ATL.

More specifically, and according to the agreement with AtlanMod, Obeo takes responsibility over a precise set of activities around the ATL technology: Quality assurance. The main responsibility of Obeo is in maintaining the ATL software at a quality level that is acceptable for wide industrial use. This task is twofold, since it includes a reactive part, mainly related to managing bug reporting and correction, and a proactive part, for the optimization of the ATL codebase, with a special attention to scalability.

Interoperability. The ATL tool is intended as a part of a complex modeling system, composed both by modules built within Obeo itself (e.g., Acceleo) and tools provided by third parties (e.g., modelers, modeling frameworks). Obeo takes care of the issues connected with the interoperability among ATL and the related modules, and implements new solutions to improve this interoperability.

Continuity.

In an industrial context it is important to guarantee that the evolution of development tools will not unexpectedly break existing projects. The integration in ATL of new technical solutions, coming from Obeo or academia, has to be performed in an incremental way, carefully preserving backward compatibility with previous versions.

User experience. One of the priorities of the industrialization of ATL is the improvement of the general user experience in the development environment. Obeo makes use of ergonomy principles for the improvement of the IDE, and adds typical facilities such as wizards and hints. The company also takes care of the internationalization of the user interface.

Release management. Obeo takes charge of the management of ATL releases, by defining milestones, building, testing, packaging and distributing new versions.

User support. Finally Obeo offers support to the user base, in both the forms of free and subscription-based support. Casual users are assisted for free by managing the newsgroup and the mailing list on the Eclipse website. Obeo also commits in extending and updating the documentation of the ATL components. On the other hand Obeo has an immediate income from offering industrial users a personalized support and training programs.

At the same time Obeo took the lead of the official (stable) version of ATL, a new branch of ATL was formed, ATL Research, to host the experimental ATL versions, under the supervision of AtlanMod. Figure 5 illustrates the mechanism for technological exchange between the two 10

P r e l i m i n a r y V e r s i o n branches of ATL. The official versions of ATL, maintained by Obeo, are publicly distributed and constitute the baselines upon which research prototypes are built. These experimental ATL Research prototypes exhibit novel solutions for particular research projects. In the cases in which these solution are considered interesting for the general public, they are integrated in the subsequent official version of ATL. Depending on the stability of the prototype and on its compliance with a set of quality criteria (e.g., scalability, backward compatibility) the module in ATL Research can be directly imported in ATL, or, more commonly, its functionality is re-engineered by Obeo before being integrated in the stable branch. We believe this two-branch strategy is a good solution to avoid any restrictions on the research activities around ATL while not damaging the stability and backward compatibily properties desired by industrail users. Moreover this open source licence also assures to any third party, especially other research groups, that this code exchange will not benefit only AtlanMod, but the whole research community . This guarantee has the effect to stimulate the contribution of new code from ATL users and researchers, with a return gain for AtlanMod and Obeo themselves.

A Sustainable Open Source Business Model for Industrializing Research Tools

We are now replicating this industrialization process with two other MDE technologies from the group: the software modernization tool MoDisco [START_REF]MoDisco[END_REF] (together with Mia-Software [START_REF]Mia-Software[END_REF]) and, more recently, our Megamodeling model management approach [START_REF] Fritzsche | Applying megamodelling to model driven performance engineering[END_REF] (with ProDevelop [START_REF] Prodevelop | [END_REF]), with the same levels of success and satisfaction for the results of the collaboration achieved so far. Therefore we plan to generalize this strategy in most of the new projects of the team.

In this sense, this section sketches our sustainable open source business model for industrializing research tools triangle that summarizes the general industrialization schema we envision. There are three main actors in this triangle: the research lab, the technology provider and a big company/user community (see Figure 6). The triangle allows connecting research groups and industrial users and match their interests.

The triangle works as follows: 11

P r e l i m i n a r y V e r s i o n The fact that this is an application-driven research (i.e. the starting point is a real problem that a big company wants to be solved) ensures the return of investment for the technology provider. Adopting open source as the common denominator in all these activities is not absolutely mandatory but facilitates a lot the communication between the different actors and maximizes the benefits of the relationship (e.g. for the research group it is easier to publish papers about it and the technology provider could commercialize services and adaptations on top of the tool for other big companies sharing the same problem). This triangle can also be used to characterize many other interesting scenarios between the actors. For instance, when the research group is not interested in the problem expressed by the big company, the company can still search for a technology provider to solve that problem. Detailing all possible relationships cannot be done here due to space limitations. This idea of intertwining research groups and industry partners has been already praised for its benefits [START_REF] Potts | Software-engineering research revisited[END_REF]. Similar to the industry-as-laboratory approach presented there, we believe that continuous communication and technology transfer, between research lab and industry, is very benefitial for both partners. However, we believe that our triangular structure can help overcoming the limitations identified in [START_REF] Potts | Software-engineering research revisited[END_REF] (such as the short-term/long-term and evolutionary/revolutionary different interests between the lab and the industry), since it gives to the re-12

P r e l i m i n a r y V e r s i o n search lab the flexibility to combine the benefits of working with real end-users and technology providers at the same time in a coherent global schema. We strongly believe that this schema can be successfully adopted by other research groups as a strategy to develop industrial quality level tools with all the benefits that this brings to the group.

Conclusion

We have presented our strategy for developing high-quality tools that can become widely used by the software engineering community: industrialization of the research prototypes thanks to the partnership with a technology provider. We believe this is the best solution to ensure that somebody external to the team (in our case, this technology provider) is in charge of all non-core research aspects of the tool development (documentation, usability, user support, etc). These aspects are key to convince external users (specially companies) to adopt our tools but cannot be taken in charge by the research teams themselves due to their limited resources. We have validated this strategy during the development of our ATL tool and we are now replicating it with other tools of the group.

We believe our experience can be useful to other research groups willing to go from proofof-concept tools to real industrial-level tools, with all the benefits this may bring to the team (in terms of visibility, feedback, project opportunities and so on). We also hope our example helps to convince as well technology providers and development companies about the advantages of participating in such joint initiatives; there is a viable business model behind it, as companies like Obeo or MIA-Software have demonstrated.

As further work, we would like to formalize a protocol for the establishment and execution of this kind of partnerships so that roles, resources and responsibilities of each participant are clear from the beginning. This will facilitate explaining this open source industrialization concept and developing new partnerships in the future. This is being investigated as part of our contribution to the OPEES European project [START_REF]Platform for the Engineering of Embedded Systems[END_REF] aimed to ensure long-term availability of innovative engineering technologies in the domain of dependable / critical software-intensive embedded systems.

Additionally, we plan to create a web-based collaboration platform for ATL extensions (we tag this project ATL labs due to its similarity with existing initiatives as the recent Eclipse-Labs.org proposal) to facilitate the autonomous experimentation and contribution by other people beside our main partner. This project will provide a sandbox where researchers can experiment with ATL and extend it for specific purposes. Such specialized extensions cannot be done on the official ATL branch since there the contribution policy is quite rigid and they don't fit in the tree structure of the ATL Research branch. ATL Labs is meant to host a number of orthogonal ATL extensions for specific needs that potential users can select and compose to get a specific ATL "flavor" adapted to their needs.

Finally, we plan to start using social networking tools to build a community of ATL users that can easily share their experience, help each other and participate in discussions about the future of ATL; the limited participative mechanisms in Eclipse (mailing lists, bugzilla, forums, ...) are not enough for this.

Acknowledgments. The present work has been partially supported by the ITEA2 OPEES European project.

13

P r e l i m i n a r y V e r s i o n

Figure 1 :

 1 Figure 1: Model-to-Model transformation principle

Figure 2 :

 2 Figure 2: The ATL perspective with a simple transformation example

Figure 3 :

 3 Figure 3: The ATL project on Eclipse.org

2

  More specifically, ATL follows the Eclipse Public License 3 See, for instance, the program of the two ATL workshops organized so far: http://www.emn.fr/zinfo/atlanmod/index.php/MtATL2009:Program and http://www.emn.fr/z-info/atlanmod/index.php/MtATL2010:Program 6 P r e l i m i n a r y V e r s i o n 4. The ATL Solution: Technical Aspects

Figure 4 :

 4 Figure 4: Components involved in the execution of an ATL transformation

Figure 5 :

 5 Figure 5: ATL and ATL Research We remark that the initial choice of licencing every part of ATL under an open-source licence (this includes both the ATL research branch and the official branch maintained by Obeo) has remarkably simplified the creation of this new business model. The open source licence automatically guarantees the possibility to transfer every ATL update between the company and the research lab.Moreover this open source licence also assures to any third party, especially other research groups, that this code exchange will not benefit only AtlanMod, but the whole research community . This guarantee has the effect to stimulate the contribution of new code from ATL users and researchers, with a return gain for AtlanMod and Obeo themselves.

Figure 6 :

 6 Figure 6: Open source triangle for the successful industrialization of research tools

At least among researchers, based on the number of works referencing and/or using ATL; there are plenty of industrial users as well but this is more difficult to quantify and compare against other tools

We say that EMF is a privileged modeling framework in the ATL toolkit because there is an optimized version of the virtual machine available for EMF that guarantees the maximum efficiency when working with EMF models


Micha L Rams
email: rams@impan.gov.pl

Jacques Lévy Véhel
email: jacques.levy-vehel@inria.fr

Results on the Dimension Spectrum for Self-conformal Measures

We consider the natural measures associated with a family of conformal iterated function systems satisfying the transversality condition but no separation condition. We provide the exact value of their generalised Renyi dimensions D q for q in a certain range.

Introduction

Let V be an open and bounded subset of R d . For each parameter t ∈ V we consider a conformal iterated function system (IFS) (f i (•, t)) k i=1 in R d depending on t. We assume this dependence to be smooth (at least C 1+β ). We denote by Λ t the limit set of the IFS, by ν t its natural measure and by s(t) the similarity dimension, i.e. the solution of the Bowen's equation P (s(t)χ t ) = 0 where χ t is the Lyapunov exponent of the IFS and P denotes the topological pressure. It is well known that dim H Λ t ≤ s(t).

If, in addition, the IFS satisfies the Open Set Condition (OSC), it is a classical result (due to Hutchinson [Hu] and Manning and McCluskey [MM]) that the Hausdorff dimension of the limit set equals s(t). In this paper we assume that the transversality condition introduced by Pollicott and Simon [PoSi] (see definition 2.1) holds. We also assume that s(t) < d for all t.

A fine analysis of the properties of the natural measure ν t of the IFS is provided by the computation of the so-called generalized dimensions or D q spectrum. These are computed as follows. Let, for q ≥ 0 and ε > 0, C q (ν t , ε) = ∫ (ν t (B(x, ε)) q-1 dν t (x) (B(x, ε) denotes the closed ball of radius ε centered at x). For q ̸ = 1, one defines the lower and upper q-dimensions as:

D - q (ν t ) = lim inf ε→0
log(C q (ν t , ε)) (q -1) log(ε) , D + q (ν t ) = lim sup ε→0 log(C q (ν t , ε)) (q -1) log(ε) .

In case the limit exists, it is called the q-dimension of ν t , denoted D q (ν t ). For q = 1, one sets:

D - 1 (ν t ) = lim inf ε→0 ∫ log(ν t (B(x, ε))dν t (x) log(ε) , D + 1 (ν t ) = lim sup ε→0 ∫ log(ν t (B(x, ε))dν t (x) log(ε) .
Alternate, equivalent, definitions exist. See in particular [HK, JJ] for potential-theoretic ones.

Generalized dimensions are extensively used for the study of chaotic dynamical systems. In addition, the Legendre transform of the function q → (q -1)D q provides an upper bound to the so-called large deviation multifractal spectrum, with equality in a number of interesting cases (the simplest one being self-similar measures with the OSC, see, e.g. [LVT, LVV]). In such cases, one says that the weak multifractal formalism holds. Since we will use the definition later, we recall it now. For each positive integer n, we consider the partition of the support of the measure µ into dyadic cubes of sizes 2 -n . For any ε > 0 and any α ∈ R, let N n (α, ε) denote the number of cubes with measure between 2 -n (α+ε) and2 -n(α-ε) . The large deviation multifractal spectrum is the function ( [F, LVV, LVT]):

f (α) = lim ε→0 lim sup n→∞ log(N n (α, ε)) n log 2 .
The existence of the L q dimension spectrum is known for the natural measure of the IFS, see [PeSo] for the linear case. This proof works (after minor changes) in nonlinear case as well, as shown in [R] (the proof in [R] is given for correlation dimension D 2 only, but the general case can be obtained in the same way). The result of Hunt and Kaloshin [HK] implies that D q = s(t) for all q ≤ 2 and for almost all t ∈ V (we explain it in more details in the third section). They also give an example, showing that the constant 2 is sharp.

The purpose of this work is to prove the following result: The results above hold for iterated function systems. They are not true for general projections of measures. For instance, we have the following example in R 2 : Example 1.3. For any s < 1 there exists a transversal one-dimensional family of projections of s-dimensional self-similar measure µ s such that D q (π θ (µ s )) < s for all q > (s + 1)/s and for all values of parameter θ.

The paper is organized as follows: In the following section we introduce the notations and describe the local geometry of IFS. There, we also consider families of IFS. The proof of Theorem 1.1 is contained in the third section. Finally, in the fourth section, we present the construction of example 1.3.

Local geometry of iterated function systems

For a conformal mapping from R d into itself we will denote

f ′ = | det Df | 1/d .
An iterated function system is a finite family (f i ) k i=1 of contractive diffeomorphisms acting from R d into itself. The limit set of IFS is the unique non-empty compact set Λ satisfying the equation

Λ = ∪ f i (Λ).
The symbolic space of an IFS is defined as Σ = {1, . . . , k} N ; its elements will be denoted by ω = (ω 1 ω 2 . . .). The finite sequences of symbols 1, . . . , k will be denoted by ω n = (ω 1 ω 2 . . . ω n ). On Σ we define some mappings. The left shift σ deletes the first digit of a sequence:

σ(ω 1 ω 2 . . .) = (ω 2 ω 3 . . .).
The right shift σ i (i = 1, 2, . . . , k) adds the symbol i at the beginning of the sequence:

σ i (ω 1 ω 2 . . .) = (iω 1 ω 2 . . .).
We write

f ω n = f ω 1 • • • • • f ωn , σ ω n = σ ω 1 • • • • • σ ωn , U ω n = f ω n (U ) and Σ ω n = σ ω n (Σ).
We define a projection from Σ into R d :

π(ω) = lim n→∞ f ω n (0). (2.1)
By [Hu], Λ = π(Σ). When x = π(ω), we will call ω the symbolic expansion of x (it needs not be uniquely defined).

We demand that all the mappings f i are smooth (at least C 1+β for some positive β) and conformal, at least in some neighborhood of Λ. The latter assumption is void in the one dimensional case but quite restricting (allowing only Möbius transformations) when d ≥ 3. We denote by U a neighborhood of Λ on which these assumptions are satisfied and assume U is bounded and open. As f i are C 1+β contractions with universally bounded contraction ratio, all f ω n satisfy the following inequality (called Bounded Distortion Property, BDP):

∃L 0 ∀ x,y,z∈U ∀ ω n L -1 0 ≤ |f ω n (x) -f ω n (y)| |x -y|f ′ ω n (z) ≤ L 0 , (2.2)
see [F], chapter 4. We can freely demand that U i ⊂ U for all i (for example, U = B r (Λ) will satisfy this). It follows that U ω n i ⊂ U ω n . The sets U ω n will be called cylinders.

We denote by λ + and λ -the maximum and minimum of local contraction ratios of all the mappings f i over all x ∈ U .

We will use sets Σ ω n = σ ω n (Σ) and call them cylinders, too (in symbolic space). It is easy to see that π(Σ ω n ) ⊂ U ω n ; the cylinders U ω n and Σ ω n will be called dual.

We introduce a metric on Σ given by ρ(ω, τ

) = |U ω n |, where ω i = τ i for all i ≤ n but not for i = n+1. If ω 1 ̸ = τ 1 , then ρ(ω, τ ) = |U |.
This metric agrees with the product topology on Σ. It is easy to check that π is a Lipschitz mapping (with Lipschitz constant 1) in the metric ρ.

We define a family of Hölder-continuous functionals on Σ:

ϕ r (ω) = r • log(f ′ ω 1 • π • σ(ω)).
There exists precisely one value r = s for which the pressure (see, e.g., [F]) of ϕ r vanishes; it is called the similarity dimension of the IFS. Let µ be the Gibbs measure (on Σ) for ϕ s (see, e.g., [BMP]) and denote by ν the projection of µ under π. We will call ν the natural measure of the IFS.

¿From the definition of Gibbs measure

µ(Σ ω n ) ≈ exp( n-1 ∑ i=0 ϕ s (σ •i (ω))) ≈ ( |U ω n | |U | ) s . (2.3)
Hence, µ is equivalent to the s-dimensional Hausdorff measure on (Σ, ρ). In particular, neither the Hausdorff dimension of Λ nor D q dimension of ν can be greater than s (as the Lipschitz mappings cannot increase the Hausdorff or D q dimensions).

For all l ≤ |U | we will define Z l as a family of all cylinders U ω n such that

|U ω n | ≤ l < |U ω n-1 |
The cylinders in Z l have diameter between l and λ -l.

By (2.3), the dual cylinders to those in Z l have measure µ between L -1 4 (l/|U |) s and L 4 (l/|U |) s for some L 4 for all l. Hence Z l has between L -1 4 (l/|U |) -s and L 4 (l/|U |) -s elements. We define the intersection numbers for cylinders from Z l :

A l = ♯{(U ω n , U κ m ) ∈ Z l × Z l : U ω n ∩ U κ m ̸ = ∅, ω 1 ̸ = κ 1 }. Let l i = |U |λ i + .
(2.4)

For such a sequence every cylinder U ω n belongs to at least one and at most some L 7 of Moran covers Z l i , where L 7 does not depend on ω n . We will now consider not a single IFS but a d-dimensional family of IFS, acting on R d . We will use t = (t 1 , . . . , t d ) as a parameter and write the dependence on t explicitly; for example, the limit set will be denoted as Λ t . The set of parameters V is assumed to be the closure of a bounded open subset of R d . We assume the contractions f i (x; t) to be C 1+β for (x, t) ∈ U × V , that is we want all the derivatives ∂f i /∂x j and ∂f i /∂t j to be C β with respect to both x and t.

Denote h ω,κ (t) = π t (ω) -π t (κ). The following definition was first introduced (in a one-dimensional situation) in [PoSi].

Definition 2.1. The family of IFS satisfies the transversality condition if there exists a constant L 5 such that for any two sequences ω, κ ∈ Σ with

ω 1 ̸ = κ 1 , if |h ω,κ (u)| < L 5 then | det D t h ω,κ (t)| |t=u > L 5 .
The following lemma wasn't explicitly stated in [R] but it was proved (under the transversality condition) in the course of proof of Theorem 1.1 Lemma 2.2. For any ε > 0 and Lebesgue-almost any t ∈ V there exists

L 6 (t) such that for all l ≤ |U | A l (t) ≤ L 6 l -2(1+ε)s(t)+d
3 Proof of the Theorem 1.1

As mentioned above, D q (ν t ) ≤ s(t) for all q. The result of Hunt and Kaloshin implies that for almost all t ∈ V the equality holds for all q between 1 and 2. By monotonicity of D q , the equality must hold for all q ≤ 1 as well. In what follows we are only interested in q greater than 2.

The first part of Theorem 1.1 is easy to prove. The strong open set condition is equivalent to the bijectivity of π. Assume π t (ω) = π t (τ ) for some ω ̸ = τ . We may freely assume ω and τ have different first symbols, otherwise we have π t (σω) = π t (στ ) and we repeat this as long as the first digits are not different. Hence, U ω m (t) and U τ n (t) intersect for all m, n. In particular, A l i (t) > 0 for all i. This can only happen for a zero measure set of parameters by Lemma 2.2. A more detailed analysis, based not on Lemma 2.2 but on Proposition 4.6 from [R], shows that this set of parameters has its upper box dimension not greater than 2 sup s(t).

Assume now that s(t) > d/2 and the assertion of Lemma 2.2 is satisfied for t. As t is henceforth fixed, we denote s = s(t) etc.

The proof works as follows. We are going to estimate from above the multifractal spectrum f (α) by estimating maximal possible number of places where many cylinder sets U ω n meet. The direct estimation by means of Lemma 2.2 is not enough because it gives us only the number of pairs of intersecting cylinder sets with different first digits of their symbolic expansion (i.e. U ω n intersects U τ m and ω 1 ̸ = τ 1 ). We will perform a more delicate estimation using the fact that if U ω n and U τ m intersect each other and ω 1 = τ 1 then the cylinder sets U σω n and U στ m must intersect each other as well (thus we get to use Lemma 2.2 on many different scales).

Let δ be a small positive constant. Given l and N , consider a set of all points belonging to at least N sets U ω n ∈ Z l and let M (l, N ) be its maximal λ -1 -l-distanced subset, i.e. points from M (l, N ) are in distance greater than λ -1 -l from each other, belong to at least N sets U ω n ∈ Z l and no point with those properties can be further added to M (l, N ). Note that two different points from M (l, N ) cannot belong to the same U ω n ∈ Z l .

Given a finite word ω n , let P (l, N, ω n ) be the subset of M (l, N ) consisting of the points that belong to at least N (1-δ) n sets U τ m ∈ Z l with the symbolic expansions beginning with ω n , ie. τ m = ω n η m-n . Let also

Q(l, N, ω n ) = P (l, N, ω n ) \ k ∪ i=1 P (l, N, ω n i) Clearly, M (l, N ) = ∪ ω n Q(l, N, ω n ) (3.1)
where the union goes over all finite sequences with |U ω n | > lλ -.

Lemma 3.1.

♯(Q(l, N, ω n )) ≤ L 1 l -2s(1+ε)+d ( |U | |U ω n | ) -2s(1+ε)+d (1 -δ) -2n δ -2 N -2 Proof. Let x ∈ Q(l, N, ω n ).
The Dirichlet principle easily shows that for any x there are two different symbols i, j such that among the sets U τ m ∈ Z l that contain x there are at least N (1-δ) n δ/k such that their symbolic expansions begin with ω n i and the same number beginning with ω n j.

Hence, there are at least

N 2 (1 -δ) 2n δ 2 k -2 pairs of sets (U τ m+n+1 , U η r+n+1 ) such that i) x ∈ U τ m+n+1 ∩ U η r+n+1 , ii) τ m+n+1 = ω n i(x)ϕ m , iii) η r+n+1 = ω n j(x)ξ r ,
iv) both τ m+n+1 and η r+n+1 do not appear again for any y ∈ Q(l, N, ω n ).

Hence, we have at least

N 2 (1 -δ) 2n δ 2 k -2 ♯Q(l, N, ω n ) different pairs for all points in Q(l, N, ω n ).
The image under f -1 ω n of any such pair is the pair of intersecting sets (U iϕ m , U jξ r ). Those sets have diameter between

lL 0 |U |/|U ω n | and lλ -L -1 0 |U |/|U ω n | by (2.
2). For any such pair let g((U iϕ m , U jξ r )) = (U iϕ m 0 , U jξ r 0 ) be the pair of their ancestors, belonging to

Z lL 0 |U |/|U ω n | .
The mapping g is uniquely defined. In addition

λ max(m-m 0 ,r-r 0 ) + ≥ λ -L -2 0 ,
hence g is at most a K to 1 mapping for some uniformly bounded K. This proves that there are at least

N 2 (1 -δ) 2n δ 2 k -2 K -1 ♯Q(l, N, ω n ) dif- ferent pairs of the form g((U iϕ m , U jξ r )).
♯M (l, N ) ≤ L 2 δ -2s/(2s-d) l -s(1+2sε/(2s-d)) N -2s/(2s-d)
where L 2 depends neither on l nor on N .

Proof. By (3.1)

♯M (l, N ) ≤ ∑ ω n ♯Q(l, N, ω n ) ≤ ∑ i ∑ U ω n ∈Z l i ♯Q(l, N, ω n ) (3.2) As n ≤ log(|U |/l i ) -log λ - -log λ + , we can estimate (1 -δ) n ≥ ( l i λ - |U | ) sε (3.3)
for δ small enough. Hence, as the summands in (3.2) are nonnegative integers, they must be zero for

( |U | l i ) 2s-d > L 1 λ -2s(1+2ε)+d - l -2s(1+ε)+d δ -2 N -2 . (3.4)
Let I be the maximal i that do not satisfy (3.4). We have

♯M (l, N ) ≤ ∑ i≤I ♯Z l i L 1 λ -2s(1+2ε)+d - l -2s(1+ε)+d ( |U | l i ) -2s+d δ -2 N -2 ≤ ≤ ∑ i≤I L 1 λ -2s(1+2ε)+d - L 4 l -2s(1+ε)+d ( |U | l i ) d-s δ -2 N -2
Substituting (2.4) we get an increasing exponential series. Its sum is (up to a constant) equal to the greatest element, which gives the assertion.

Note that δ depends on ε but nothing else. Substituting N = l -s+α for d/2 ≤ α < s, we get

♯M (l, l -s+α ) ≤ c(ε)l s(2α-d)/(2s-d)-O(ε) (3.5)
The estimation for ♯M (l, N ) obtained here will allow us to obtain an estimation on the multifractal spectrum of ν.

Proposition 3.3. f (α) ≤ lim sup l→0 log ♯M (l, l -s+α ) -log l
Proof. We fix l for a moment. The natural measure ν is a projection of measure µ defined on Σ , which in turn can be presented as union of Σ ω n over

{ω n ; U ω n ∈ Z l }. Hence, ν is a sum of approximately l -s separate measures π * (χ(Σ ω n ) • µ)
, each supported on a d-dimensional approximate ball of diameter between λ -l and l (by definition of Z l ) and each of norm between L -1 4 (l/|U |) s and L 4 (l/|U |) s (by (2.3)). Given any set Z ⊂ R d the following estimation holds:

L -1 4 (l/|U |) s ♯{U ω n ∈ Z l ; U ω n ⊂ Z} ≤ ν(Z) ≤ L 4 (l/|U |) s ♯{U ω n ∈ Z l ; U ω n ∩Z ̸ = ∅} (3.6)
We will make two claims. Firstly, for any x ∈ M (l, N ) we claim that ν(B l (x)) ≥ N L -1 4 (l/|U |) s . Let us denote

L 10 = inf ω n vol(U ω n ) |U ω n | d
(this number isn't zero because U ω n = f ω n (U ) and maps f ω n have uniformly bounded distortion). Our second claim is that for any

x ∈ R d if ν(B l (x)) ≥ N L 4 L -1 10 (l/|U |) s 4 d λ -d -then dist(x, M (l, N )) ≤ (2 + λ -1 -)l.
Together those claims mean that ♯M (l, N ) is (up to a constant) a number of separate balls of radius l and measure at least cN l s . The assertion then follows from the definition of multifractal spectrum.

The first claim follows directly from (3.6) because B l (x) must contain all U ω n ∈ Z l that contain x. To prove the second claim, consider a ball B l (x) of big measure:

ν(B l (x) ≥ N L 4 L -1 10 (l/|U |) s 4 d λ -d - By (3.6), B l (x) intersects (hence, B 2l (x) contains) at least N L -1 10 4 d λ -d - sets from Z l .
The sum of volumes of those sets is not smaller than 4 d N l d , i.e. more than N times greater than the volume of B 2l (x). Hence, there is a point y ∈ B 2l (x) belonging to at least N of them. Either y belongs to M (l, N ) or there is another point in M (l, N ) in distance smaller than λ -1 -l from y (hence in distance smaller than (2+λ -1 -)l from x), so the second claim is proved. Proposition 3.3 together with (3.5) gives us the upper bound for the multifractal spectrum:

f (α) ≤ s(2α -d)
2s -d for α < s. Using Legendre transform we get D q (ν) = s for q ≤ s/(s -d/2) and we are done.

The last case that remains to be considered is s(t) = d/2. Proposition 3.2 isn't working in this case but Lemma 3.1, Proposition 3.3 and formulas (3.2), (3.3) are. Substituting the formulas into the assertion of Lemma 3.1 and using inequality l i ≥ l we get the estimation of the form

♯(Q(l, N, ω n )) ≤ cl -3dε/2 δ -2 N -2
By (3.4), for M (l, N ) to be nonempty Q(l, N, ω n ) must be nonempty as well for at least some ω n and it is only possible when

N ≤ c 1/2 δ -1 l -3dε/4
It implies that the multifractal spectrum f (α) equals -∞ for all α < s -3dε/4. As ε can be chosen arbitrarily small, the graph of f must actually contain only one point (d/2, d/2) and the assertion follows.

Example

The example we present can be seen as a generalization of the Hunt and Kaloshin example.

Let λ = 2 -1/s . Let I 0 = [0, 1] × {0} be an interval of length 1. We will construct inductively a family of unions of intervals in the following way. For every interval

I (i) n ⊂ I n we first remove from I (i) n the middle part of length |I (i) n |(1 -2λ
) and then rotate one of the resulting intervals (clockwise) by an angle 2 -n-1 π. The union of all the resulting intervals will be denoted I n+1 . It is easy to see that I n will be an union of 2 n intervals of length λ n each and their directions are of the form i2 -n π (see figure).

For any

I (i) n , let J (i)
n be the ball of diameter

I (i) n . Let K (i)
n be the intersection of J n form a decreasing family of compact sets. We denote the limit set by K. We distribute a measure ν on K in such a way that ν(K (j) n ) = 2 -n for all j.

The sets I 0 (up, solid line), I 1 (middle, solid lines), I 2 (bottom, solid lines).

Consider a family of all orthogonal projections of ν on lines in R 2 . We denote the projection in direction θ by π θ and let ν θ = π θ * ν. For any n and any direction θ there is some i for which the angle between θ and the direction of I (i) n is smaller than 2 -n π. Hence, the projection of K (i) n in direction θ is an interval of length not greater than (2 + π)λ n 2 -n . At the same time, the measure ν θ of this interval is at least 2 -n . Letting n tend to ∞, we will get a point for which the pointwise dimension of ν θ is at most -log 2/ log(λ/2) = s/(1 + s). Hence, D q (µ θ ) < s for all q > (s + 1)/s.

Consider now the standard s-dimensional self-similar measure µ, ie. normalized s-dimensional Hausdorff measure on middle-γ Cantor set, γ = (1 -2λ). The measure µ is bi-Lipschitz equivalent to ν. Let us denote the conjugacy map by h. As the orthogonal projections form a transversal family and bi-Lipschitz conjugacy preserves transversality, the maps h θ = π θ • h form a transversal family of projections of a self-similar measure but do not preserve its D q dimension for q > (s + 1)/s.

  n+1 are the two intervals obtained from I

  Those are pairs of intersecting sets from Z lL 0 |U |/|U ω n | with different first symbols, hence the number of such pairs cannot exceed A lL 0 |U |/|U ω n . The assertion then follows by Lemma 2.2.

Proposition 3.2. For δ small enough,

* supported by Polish KBN Grant No 2P0 3A 034 25