Jean Bézivin
email: bezivin@gmail.com

Hugo Brunelière
email: hugo.bruneliere@gmail.com

Frédéric Jouault
email: frederic.jouault@gmail.com

Ivan Kurtev
email: ivan.kurtev@gmail.com

Model Engineering Support for Tool Interoperability

In this paper we want to show how MDE (Model Driven Engineering) approaches may help solving some practical engineering problems. Our view of MDE is not based on the usage of huge and rather monolithic modeling languages like UML 2.0 but instead on small DSLs (Domain Specific Languages) defined by well focused metamodels. As a consequence we use a rather "agile" view of MDE where each tool is characterized by one of several metamodels and where the interoperability between tools is implemented by specific model transformation operations. We base our discussion on a practical illustrative problem of bug-tracking in a collaborative project involving different partners using tools at different maturity levels. We conclude by discussing the help that MDE approaches may bring to solving these kinds of situations.

Introduction

Today's software development practices rely on a dynamic set of languages, tools, and processes. Development teams are often geographically distributed and their work usually needs an integration step to form a complete product. However, before this integration is achieved the differences at the syntactical level of the created artifacts (e.g. different file formats, data representation schemes) and at the semantic level (differences in the underlying conceptual models, problems with language expressiveness, etc.) must be reconciled. In other words, the integration problem is preceded by a problem of interoperability at various levels.

One possible interoperability problem is the interoperability among tools. Currently the market offers a large set of software tools coming from various vendors for achieving a broadening spectrum of different purposes. The competition between vendors often leads to proprietary solutions or to solutions that slightly deviate from standards. Apart from this, a large set of partially supported or not supported legacy tools introduces an additional complexity to the problem.

In general, to enable interoperation between tools, the artifacts created with one tool should be somehow accessible from other tools. One possible solution is to apply transformations between various formats employed in different artifacts. The Model Driven Engineering (MDE) approach prescribes the utilization of modeling practices, mainly models, metamodels and model transformations and should provide the required capabilities to perform such transformations.

In this paper we focus on the tool interoperability problem in the context of software development and more specifically on the interoperability of bug tracing systems. We use the AMMA (ATLAS Model Management Architecture) model engineering platform as a means for representing various tools and their underlying conceptual models and to specify and execute transformations among them. The more general goal we pursue is to generalize the experience gained in this domain and to try to attack interoperability problems in other domains too.

We have experimented with the model engineering approach to interoperability by using a case study in which three different tools were used for bug tracing. We developed bridges between these tools by using model transformations. The results showed that the approach is promising and many problems, in this particular area, can be efficiently solved on the basis of MDE principles.

All the artifacts described in this paper (mainly source of metamodels and transformations) are available as open source contributions in the Eclipse GMT project [START_REF]Eclipse GMT Project (General Model Transformer[END_REF] together with the transformation engine and associated development tools (ATL).

This paper is organized as follows. In section 2 we present the motivating example treated in the paper. Section 3 describes our approach to interoperability based on model engineering. In this approach metamodels are built for every tool and transformations between the models created by the tools are defined. Section 4 presents the metamodels and section 5 presents the transformations. Section 6 presents a discussion and a short comparison with related work. Finally, section 7 concludes the paper.

Motivating Example

Problems of tools interoperability can be found in many and various domains. Software quality control is one of these domains because several tools are often used to ensure the quality of a software product. Since this is a quite wide domain, in this paper we will focus on a sub-domain in order to illustrate our approach.

We take an example of "bug-tracing" or "bug-tracking" in the case of a software product development. Assume that three teams are currently working on the same product at the same time but on different modules of this product. Teams may be geographically distributed, may have different levels of maturity of the used development process, may have different experience for the team members, and may consequently use different tools. The global situation may be described as follows:

• Team "A" is developing the first module by using an Excel workbook with a specific format to track or trace bugs; • Team "B" is working on the second module and uses Bugzilla [2] which is a free bug-tracking system; • Team "C" is developing the third module and uses Mantis Bug Tracker [START_REF]Mantis Bug Tracker official site[END_REF] which is another free bug tracking system;

A fourth team (that we name Team "D") must integrate the various modules developed by this three teams into a complete software solution. It also has to deal with all the bugs that have been detected but not yet resolved for each module.

The problem is that each team has used a different tool for keeping track of bugs. So in that case, how to succeed in centralizing bug-tracking, i.e. how to be able to interoperate from a tool to another without losing critical information about detected bugs? Furthermore the level of maturity of each team may dynamically evolve, each one learning from the global project. A given team may thus upgrade at some point in time its practices to those used by another one.

The AMMA model engineering platform (ATLAS Model Management Architecture) [START_REF]The AMMA Platform[END_REF] offers a means of solving this type of problems by using metamodels and transformations between models conforming to these metamodels.

Proposed Approach

Our approach to interoperability between bug tracking tools is based on the principles of model engineering. In this approach we treat the information described by a bug tracking system as a model that conforms to a given metamodel (usually specific to the tool being employed). This makes it possible to use model transformations to convert the description of bugs from one tool to another. The AMMA platform provides the capabilities to define metamodels and to define model transformations. It is built on top of Eclipse Modeling Framework (EMF) [START_REF]Eclipse Modeling Framework (EMF[END_REF]. The general overview of the approach is presented in Figure 1.

I n je c t f r o m X M L f il e s E x t r a c t in t o X M L f il e s

Figure 1 Overview of our model engineering approach to interoperability

In this approach, each different "bug-tracking" tool is described by a metamodel. Each tool's metamodel is linked to others by the "logical" pivot: transformations based on these metamodels to the pivot and from the pivot to the metamodels are implemented. This pivot is also a metamodel. It abstracts a certain number of general concepts about "bug-tracking". Moreover, because in this example each tool uses an XML format to import/export data, we need to create an XML metamodel 1 . The aim of this metamodel is to make possible the injection of the content of an XML file into a model and the extraction of the content of a model into an XML file. Each model that we will have to handle will conform to one of these metamodels (tool's, pivot's or XML's one). Thus there is a transformational bridge between each of the tools shown in Figure 1 and, in this manner, each of these tools can interoperate with the others.

As a consequence, it is possible to easily add a new tool to the previously described system by:

• creating the associated metamodel;

• building the bridge (composed of two transformations) between this metamodel and the logical pivot metamodel; • making the XML injector/extractor for this metamodel;

After we have set up the principles of our approach, we are able to present the metamodels and the transformations that have been implemented. Section 4 presents the metamodels and Section 5 explains the model transformations.

Metamodel Support

Metamodels (lying at the M2 level of the OMG metamodeling stack) are entities used to define domain specific languages (DSL) related to data formats and tools. In the context of the AMMA platform metamodels conform to KM3 (Kernel MetaMeta-Model), which is a metametamodel (M3 level) close to Ecore [START_REF]Ecore[END_REF] and EMOF 2.0 [START_REF]Essential MOF 2.0 (Meta-Object Facility[END_REF]. KM3 provides a textual concrete syntax quite similar to the Java notation.

In our approach we may distinguish several kinds of metamodels:

• Input/Output metamodels that in most of the cases describe the format of input/output files such as XML files; • Physical metamodels that describe the domain specific languages used by tools;

• Logical metamodels that are created to generalize a certain number of concepts common to several tools and thus to several DSLs;

This section provides the descriptions of the metamodels used in our example by respecting the classification given above.

The Input/Output Metamodel: XML Metamodel

Microsoft Excel, Bugzilla, and Mantis (and a lot of tools in general) do not natively use XMI (the OMG standard for serializing and exchanging models and metamodels). Instead they use a general XML format to import/export data. It is thus necessary to define an XML metamodel in order to be able to inject the content of XML files into models and to extract the content of these models into other XML files.

The simple XML metamodel we use is described in Figure 2. In this metamodel each element is a node which is identified by its name. The root element is the root of an XML document. It can contain several elements which can, in turn, contain other elements. Moreover, each element can have a list of attributes and text nodes.

The Physical Metamodels

In our example, we have three metamodels regarded as physical metamodels. Each different "bug-tracking" tool or general tool used for bug-tracking (Bugzilla, Mantis Bug Tracker, Excel) used by a team is associated to a metamodel of this kind. This subsection presents in more details these three physical metamodels.

SpreadsheetMLSimplified (Excel)

Microsoft Excel uses an XML language called SpreadsheetML to import/export Excel workbooks in the XML format. This is a very complex XML language defined by several XML schemas allowing to deal with most of the information saved in the Excel binary format '.xls'. Since handling of relatively small metamodels is more efficient, we only use a part of this language: a sufficient subset to preserve the global structure of an Excel workbook and to contain the raw data.

The simplified metamodel of Excel called SpreadsheetMLSimplified is presented in Figure 3.

Figure 3 Simplified version of the Excel metamodel (SpreadsheetMLSimplified)

According to this metamodel an Excel file is a workbook. A workbook can have several worksheets. Each worksheet can have a table which is composed of table elements (columns, rows and cells). A table contains columns and rows. Each row consists of several cells. The cells contained in rows store the raw data of a given type.

Bugzilla

Bugzilla is a free "defect-tracking" or "bug-tracking" system originally developed by the Mozilla Foundation. A huge database allows it to store a large amount of information about a lot of bugs. These data are too complex to be easily handled by SQL requests. However, it is possible to use a Perl script to import/export bugs' data in a simpler XML format. The data in XML files conform to a simple DTD.

The simple Bugzilla metamodel presented in Figure 4 is inspired by this DTD.

Figure 4 Simplified version of the Bugzilla metamodel

A Bugzilla model is a set of bugs. Each bug is identified by an "id" string and contains much information about the bug itself but also about the people who deals with it, the software product that is concerned with, etc.

Mantis

Mantis is a web-based bug-tracking system written in PHP that uses a MySQL database. Once again, such as for Bugzilla, the database is described by a complex relational schema. Mantis also allows importing/exporting bug data in XML files. The XML files conform to an XML schema. The Mantis metamodel inspired by this schema is presented in Figure 5.

Figure 5 Simplified version of the Mantis metamodel

A bug in Mantis is named "issue". Consequently, a Mantis model is a set of issues, each issue being identified by a unique number. Similarly to Bugzilla, an issue contains much information about itself, its software product, etc.

The "Pivot" Logical Metamodel: SoftwareQualityControl

By looking at the Bugzilla and Mantis metamodels, we find a lot of similarities. The information contained in a Bugzilla "bug" or in a mantis "issue" is often based on a similar structure. This information is also quite similar to the one contained in the specific format of Excel workbook in our example. That is the reason why it is necessary to create a logical metamodel which will be used as a "pivot" to facilitate the construction of bridges from a metamodel to another. By this skew, it will be simpler to improve interoperability between the various tools related to these metamodels.

Moreover, it would be interesting to allow the management of software quality control in general, not only its bug-tracking aspect. So the metamodel has to be general enough to easily allow adding of new types of software quality controls even if, for our example, we only need a "bug-tracking" logical metamodel.

The logical metamodel we created is depicted in Figure 6.

Figure 6 Software quality control metamodel

A software quality control model is composed of several controls. Each control is defined by specific information about the component and the element which are concerned, about the person who is responsible for the control, the date, etc. The main information is the type of the control. It determines what kind of actions has been performed and consequently what kind of data have been saved. In the case of our example, we only create BugTracking type but it could have a lot of other control types. In this type, the control consists of a set of bugs in which each bug is identified by a unique number. The information associated to a bug is identical to the one we can find in Bugzilla and Mantis.

Model Transformations

Model transformations are the second type of components in our proposed approach to solving problems of interoperability between several bug-tracing systems. In the context of AMMA platform transformations are written in ATL (ATLAS Transformation Language) [START_REF] Atl | ATLAS Transformation Language Reference site[END_REF]. ATL is a QVT-like language [START_REF]OMG MOF 2.0 Query/Views/Transformations RFP[END_REF] for transformation of models (M1 level), which conform to metamodels (M2 level) previously written in KM3 (see section 4).

Figure 7 Excel-to-Bugzilla and Excel-to-Mantis bridges

In fact we do not implement direct bridges between these tools. As was mentioned in section 3 we use the logical metamodel SoftwareQualityControl as a pivot and therefore every model used in one of the tools is transformed to an intermediary model conforming to the logical pivot.

We can see that an Excel file in XML is the entry point of the two bridges. This file has to be injected into an XML model before being transformed into an Excel (SpreadsheetML) model and a SoftwareQualityControl model. Then, this Software-QualityControl model can be transformed into Bugzilla and Mantis models. Finally, these two models have to be transformed into XML models in order to be extracted into well-formed XML documents. These files are the exit points of the two bridges. Next sections explain each transformation in details.

Excel to Software Quality Control

This transformation is common to the two bridges. Here is the point of using the logical metamodel (SoftwareQualityControl) as a pivot. In this manner, we only need one transformation instead of two. Moreover, the creation of a new bridge to another tool will be facilitated because a part of this bridge is already made.

To make this transformation we proceed in three steps. There are detailed below.

First

Step: Inject XML Microsoft Excel is able to save its files as XML documents. So XML is the input metamodel of our two bridges. That is the reason why we first need to inject the content of the XML file in an XML model (conforming to the simple XML metamodel described in Figure 2). The XML injector is integrated into an Eclipse ATL plug-in from the standard ATL perspective.

Second Step: XML2SpreadsheetMLSimplified

This transformation is a simple mapping from an XML source model representing the content of an Excel file in the SpreadsheetML dialect to a SpreadsheetMLSimplified target model. As the target model has to conform to the simplified SpreadsheetML metamodel (Figure 3), the main work of this transformation is preserving the global structure of the Excel workbook in order to store only the raw data. All the information about styles, formatting and printing options is removed in the target model.

Third Step: SpreadsheetMLSimplified2SoftwareQualityControl

Now that we have a SpreadsheetML source model, we are ready to transform the data contained in the Excel workbook into a SoftwareQualityControl target model (conforming to the metamodel described in Figure 6) which will be then used as a "pivot".

As the format of the Excel table contained in the source model is well-known, we can extract the required information quite easily from it and construct the target model. At the end of this step, all the necessary information stored in the Excel workbook has been recovered and correctly formatted into the target model.

Software Quality Control to Bugzilla

This transformation is specific to Bugzilla bug-tracking system. It follows the Excelto-SoftwareQualityControl transformation structure. Once again, it is composed of three steps which are detailed below.

First Step: SoftwareQualityControl2Bugzilla

The source model is the SoftwareQualityControl "pivot" model. Most elements of it, such as the bug number, and the bug status can easily find their equivalent in the Bugzilla target model. But for some other elements it is more difficult to find an equivalent. This can cause a loss of information in certain cases. Moreover, some required attributes in Bugzilla have no equivalent in the source model so they have to be initialized with a default value.

The aim of this transformation is to construct a valid Bugzilla model from the "pivot" model. So, in all cases, the generated Bugzilla model conforms to the Bugzilla metamodel (Figure 4).

Second Step: Bugzilla2XML

Files used to import/export Bugzilla's data are XML documents: XML is the output metamodel of the "Excel-to-Bugzilla" bridge. As a consequence we need to transform the source Bugzilla model to an XML target model that conforms to the simple XML metamodel provided in Figure 2. The mapping between Bugzilla and XML is really obvious since the Bugzilla metamodel is based on a DTD. The content of the produced XML model conforms to the Bugzilla DTD.

Third Step: XML2BugzillaText

The produced XML model must be extracted to an XML file in order to be used by Bugzilla. The extractor is based on an already existing "XML2Text" transformation that generates a valid and well-formed XML document.

The end of this step is the exit point of the "Excel-to-Bugzilla" bridge.

Software Quality Control to Mantis

This transformation is specific to Mantis Bug Tracker. It follows the "SoftwareQuali-tyControl-to-Bugzilla" transformation structure. To make this transformation we also proceed in three steps which are described below. Because this transformation presents many similarities with the "SoftwareQualityControl-to-Bugzilla" one, we will not describe it in detail.

First Step: SoftwareQualityControl2Mantis

The observations we made for the "SoftwareQualityControl2Bugzilla" transformation are also valid for this one. However, it is important to note that Bugzilla and Mantis metamodels (Figure 4 and Figure 5) have some differences: some elements in the Mantis metamodel, for example "reproducibility", do not have any equivalent in the Bugzilla metamodel. In all cases, the produced Mantis model conforms to the Mantis metamodel.

Second Step: Mantis2XML

For the same reasons as for the Bugzilla case, an XML target model is generated from the Mantis source model. The content of this target model conforms to the Mantis XML schema.

Third Step: XML2MantisText

As the "XML2BugzillaText" transformation, this one is based on the "XML2Text" transformation. The produced XML file is reusable by Mantis. The end of this step is the exit point of the "Excel-to-Mantis" bridge.

Discussion & Related Work

The problem of interoperability has been addressed by different research communities. Different levels of interoperability may be identified: syntactic interoperability and semantic interoperability. Here we briefly outline some of the existing work in this area without claiming exhaustiveness.

In Business-to-Business electronic commerce different companies exchange electronic documents that may be written in different XML languages thus causing an interoperability problem. This problem may be solved by XSLT transformations or by splitting the transformation task at two levels as described in [START_REF] Omelayenko | A Two-Layered Integration Approach for Product Information in B2B E-commerce[END_REF]. This splitting separates the syntactic and semantic mapping in two subtasks. By using only XSLT transformations these tasks are performed in a single transformation program.

A similar problem is observed in the area of knowledge representation where a domain may be described by different ontologies that carry the same meaning but are expressed in different ways. This problem has been addressed by applying transformations between ontologies [START_REF] Maedche | MAFRA -A MApping FRAmework for Distributed Ontologies[END_REF].

Finally, in the area of integration of heterogeneous XML data sources a pivot conceptual model is sometimes built to abstract from the syntactical differences and to provide a common and abstract view over different sources. The approach described in [START_REF] Amann | Querying XML Sources Using an Ontology-Based Mediator[END_REF] relies on ontology language for specifiying the pivot and on XPath as a base for transformations from the logical pivot and the underlying XML data.

The main difference of these approaches compared to ours is that they are usually performed in the context of only one technical space [START_REF] Kurtev | Technical Spaces: An Initial Appraisal[END_REF] (e.g. XML in [START_REF] Omelayenko | A Two-Layered Integration Approach for Product Information in B2B E-commerce[END_REF] and ontologies in [START_REF] Maedche | MAFRA -A MApping FRAmework for Distributed Ontologies[END_REF]), or in a fixed number of spaces. In our approach it is possible to deal with an arbitrary number of technical spaces and their associated tools provided that the metamodels employed by the tools are built and injectors of their content are defined. From this point of view an MDE-based approach allows a uniform treatment of various technologies on the basis of MDE principles.

Our approach allows a relatively easy addition of new tools that have to operate with the existing ones. The only thing that is required is to build new physical and input/output metamodels. After this, bridges from these models to the 'pivot' model have to be defined. This evolution scenario may be complicated if there are significant differences between the pivot and the newly added physical metamodel. In that case the pivot may need to be updated.

Conclusion

Many lessons learnt in this project may be applicable more generally to various contexts and goals. This section will try to outline some of them.

In our work we have a specific bias to using "agile metamodeling" with small metamodels. This contradicts many mainstream proposals that use large and predefined "one size fits all" metamodels like UML 2.0. We need more experiments to assess the advantages and drawbacks of each of these approaches named below "agile modeling" and "monolithic modeling".

Agile modeling presented here is based on the idea that a new DSL (defined by a metamodel) should be created (or reused) for each specific task or situation. On the contrary, monolithic modeling (mainly illustrated by typical UML 2.0 approaches) is based on the idea that a unique (or unified, or united) modeling language may be used for most activities. No new metamodel has thus to be defined. Instead we may possibly specify that we use only some part of the language (informal restriction) or that we use some controlled extension to the language, by the way of UML profiles for example.

The monolithic modeling approach has some apparent advantages: • No metamodel to create;

• No large library of metamodels to manage and maintain; • One consistent language framework where all the interactions between components (e.g. between classes, use cases, statecharts, activities, etc.) have already been accurately specified; • Only one language to learn; Each of these advantages is a drawback for the agile approach which seems much more demanding:

• It needs metamodel designers, i.e. highly skilled personnel in the project;

• It has to manage the fragmentation of all these created or reused metamodels; • The transformations are exogenous transformations (different source and target metamodels) whereas in the monolithic approach we have mainly endogenous transformations (i.e. UML-to-UML);

Our definitive choice of the agile modeling approach is based on the experience accumulated in the AMMA and previous model engineering projects: • A transformation is more precise if the source and target metamodels closely fit the transformation itself. This is similar to typing issues in programming languages, metamodels playing the role of types and models the role of variables or parameters; • Experimental evidence has shown that the work involved in defining a transformation is rather concentrated on the definition of the source and target metamodels. This is also related to the previously mentioned issue;

We are well aware of the remaining difficulties of agile modeling, mainly due to the fragmentation issue already mentioned. However we do believe that, in the end, this option will prevail because of several advantages: • It is easier to work by modular extension, starting from small metamodels, than to work by restriction, masking the facilities that one does not need for a particular task; • It is easier to define with accuracy a small metamodel than a huge metamodel; • The work of defining a small metamodel (like Excel, Bugzilla or Mantis) consists mainly of explicating the understanding of various tools or situations. This work should have to be done anyway. Using DSLs and specific metamodels only offers a precise framework and notation to do it; • When we will have the correct infrastructure to handle vast libraries of metamodels, the expertise gained in projects like the one described in this paper will be efficiently reusable and adaptable to similar contexts;

In the present work we have mainly considered tool interoperability based on data stream exchange, the format and content of these streams being captured by metamodels. A possible extension would be to deal with the dynamic behavior of these tools, captured by other forms of state-based or event-based metamodels. Even if this is more complex to handle, the general approach would still be very similar.

Node-

  Figure 2 A simple XML metamodel

In the AMMA platform, XML is considered as a technical space with standard projectors (injectors/extractors) to/from the base MDA technical space. Other different technical spaces (e.g. EBNF) could have been similarly considered.

Acknowledgements

This work has been partially supported by a grant from Microsoft Research (Cambridge) and by the ModelWare IST European Project #511731. We thank also all the colleagues of the ATLAS group that have participated in this work and specially, Freddy Allilaire, Marcos Didonet del Fabro, David Touzet and Patrick Valduriez.

Overview

In the previous sections we described a library of small metamodels related to bugtracking. We can use ATL to implement bridges between the different tools of our example which are Microsoft Excel, Bugzilla and Mantis. Several bridges are possible and interesting to implement. We have experimented with "Excel-to-Bugzilla" and "Excel-to-Mantis" bridges for this paper. These bridges are implemented as chains of model transformations. An overview of the bridges is given in Figure 7.

Microsoft


Éric Vépa

Jean Bézivin

Hugo Brunelière

Frédéric Jouault

Measuring Model Repositories

Keywords:

We first present a model repository that has been built as part of the open source Eclipse GMT/AM3 project (Generative Modeling Technology/ATLAS MegaModel Management). Several contributed artifacts present in this repository are organized into sets of models of similar nature called zoos. The structure of the repository will be rapidly described. Its content is very rapidly extending, providing a publicly available source of experimental data to evaluate real life sets of model engineering artifacts. As an initial experiment, this paper shows how the elements contained in the AM3 zoos can be measured. Some examples of such measurements are provided for illustration purposes.

INTRODUCTION

We first present a model repository that has been built as part of the open source Eclipse GMT/AM3 project (Generative Modeling Technology/ATLAS MegaModel Management). Several contributed artifacts present in this repository are organized into sets of models of similar nature called zoos. The structure of the repository will be rapidly described in section 2. Its content is very rapidly extending, providing a publicly available source of experimental data to evaluate real life sets of model engineering artifacts. As an initial experiment, this paper shows how the elements contained in the AM3 zoos can be measured. Some examples of such measurements are provided for illustrative purposes.

In addition to the description of the AM3 open source model repository initiative, this paper introduces several new research contributions. A classification of abstract models is presented with several advantages allowing dealing similarly with terminal models or metamodels when necessary. This conceptual framework has been followed by the physical implementation of the repository. A set of tools have been built to support the approach.

In [START_REF] Bézivin | Using ATL for Checking Models[END_REF] we have proposed to use model transformation to check any kind of models. The result of such an operation is a diagnostic model conforming to a diagnostic metamodel. This strong result could be applied to any zoo of models. For example the zoo of KM3 metamodels [START_REF] Bézivin | KM3: a DSL for Metamodel Specification[END_REF] (i.e. models conforming to KM3) contains several consistent metamodels, that have been used in several practical transformations. It also contains some non consistent models, for example incomplete fragments of metamodels. This is done on purpose, to illustrate that the zoo contains real life artifacts, of various qualities. As a result, it is interesting to apply some automated checks on all the models of a given zoo to get the consistency diagnostic.

In the present contribution we discuss a new and different result. Similarly to the approach presented in [START_REF] Bézivin | Using ATL for Checking Models[END_REF], we propose here to implement elementary or composite measures on models as transformations. Here again we use the ATL transformation language [START_REF]ATL "ATLAS Transformation Language" official site (Eclipse/GMT subproject[END_REF] to practically illustrate the approach. The various measures on models may be expressed as transformations. These transformations are themselves contributed to the library of transformations (the zoo of transformations). It is then possible to measure transformations and even measure transformations.

The AM3 Model Repository

The GMT/AM3 project is hosting a repository of models [START_REF] Bézivin | KM3: a DSL for Metamodel Specification[END_REF], [START_REF] Bézivin | Model-Based DSL Frameworks[END_REF]. By model we mean here as well terminal models (like a UML model) or metamodels based on a given metamodel like MOF 2.0. Terrminal models may be based on any kind of metamodel. Figure 1 summarizes the organization of this repository. In MDE (Model Driven Engineering), models are first class entities. Models are organized in three different categories: terminal models, metamodels, or metametamodels. Each model conforms to its reference model, i.e. a metamodel or a metametamodel. It is important to note that the reference model of a metametamodel is always itself. A terminal model is a representation, that conforms to a given metamodel (its reference one) and that is also a representation of a real world system.

Model

MetaMetaModel Transformation

TerminalModel

Transformations and megamodels are examples of terminal models with particular properties. A transformation is a model that can be processed (with a virtual machine for example) in order to build a target model from a source model, both of them conforming to a metamodel that can be different.

The following definitions, related to the core concept of model, have been taken from [START_REF] Bézivin | Model-Based DSL Frameworks[END_REF] before being reformulated: Definition 1. A technical space [START_REF] Kurtev | Technical Spaces: An Initial Appraisal[END_REF] [13] is a model management framework, belonging to the "modeling world", with a set of tools that operate on the models definable within the framework.

Definition 2. A system is a delimited part of the world (the "real world") considered as a set of elements in interaction. It can be represented in terminal models.

Definition 3. A model is a representation of a given system. For each question of a given set of questions, the model will provide exactly the same answer that the system would have provided in answering the same question. T . Its reference model is a transformation metamodel (like the metamodel of the ATL language for example ). [START_REF]ATL "ATLAS Transformation Language" official site (Eclipse/GMT subproject[END_REF] Definition 9. A megamodel is a terminal model such that all its elements are models (i.e. all kinds of modeling artifacts and modeling tools like terminal models, metamodels, metametamodels…). It is a representation of a "real world" working zone. We consider this concept as the core of our GMM approach but also as a central part of the "modeling in the large" principle discussed in [START_REF] Bézivin | Modeling in the Large and Modeling in the Small[END_REF]. Definition 10. A zoo is a megamodel such that all models that compose it have the same metamodel (i.e. the same reference model). The kind of modeling artifact that can be found in a zoo may vary (as an example, the "Atlantic zoo" and the "ATL transformation zoo" which are located in [START_REF]ATLAS MegaModel Management[END_REF] are zoos, respectively of metamodels and of transformations). Alternatively, a zoo may be considered as a view on a megamodel. This view may be implemented as a transformation for example. A zoo may have several mirrors, each of them having this zoo as original zoo. Definition 11. A mirror zoo is a zoo that has been automatically generated, by the execution of a given transformation, from a specified original zoo. There are several types of events that can be the triggers of the generation, or regeneration, of a mirror zoo (as an example, when a modification occurs in the original zoo…).

A preliminary original description of the AM3 project in general terms (its presentation, its motivations, its use cases, and its global objectives) has already been given in [START_REF] Bézivin | Modeling in the Large and Modeling in the Small[END_REF]. However the content of the AM3 project has much evolved during the recent period. In fact, this project currently offers to Eclipse community's users some general documentations, three functional free-downloadable plugins and two zoos (with several mirrors for one of the two zoos).

As previously mentioned, the AM3 project already provides many MDE resources which are mainly at this time, metamodels and transformations. In fact, three zoos and several mirrors are currently freely available in the AM3 project: Zoo 1. The Atlantic Zoo: It is composed of metamodels expressed in KM3 (Kernel MetaMetaModel) format [START_REF] Bézivin | KM3: a DSL for Metamodel Specification[END_REF]. This zoo has several mirrors that are auto-generated from it by using model transformations in ATL (the number of mirrors is variable and evolving, with new mirror zoos forthcoming like one in the Prolog language):

• Zoo 3. The AMW Zoo: It is composed of weaving metamodels and extensions of weaving metamodels expressed in KM3 format.

For the moment, it provides the AMW weaving core metamodel and some already defined basic extensions metamodels.

All files contained in these zoos or mirror zoos are directly downloadable in the "Zoos" page of the AM3 Project. Several other mirrors of the Atlantic Zoo, as well as mirrors of the ATL Transformation Zoo, may be created and added to the list of available zoos in this project. The MDE artifacts (internal ones or imported external ones) may also be stored locally or geographically distributed.

However new zoos are currently being built in various formalisms, for example zoos of terminal models. These may be for example UML 2.0 models, but also other models expressed in XMI and conforming to any other metamodel than UML. Several of these terminal models will be available soon from the AM3 federation of zoos.

MEASURING MODELS

With several hundreds of models directly contributed or generated in the AM3 zoos, it is now possible to perform several investigations on this experimental material. For example measuring the various models may bring interesting insight into the consideration of these models. Furthermore comparing similar measures applied to models of various origins may bring interesting observations. The initial metrication campaign is outlined below. It applies mainly to the various metamodels. The idea is to collect measurement data from metamodels, to compare them, establish producer profile, etc. For doing this, metrics on metamodels must be defined. A set of existing metrics on class diagram can be reused on metamodels. About the measures, they own a name and can be simple or complex. A simple measure also owns a double value and is used for metrics like TNC (Total Number of Classes) or DIT (Depth Inheritance Tree). More complex measures have not yet been implemented. We obtain an output model of measures with the hierarchy and model elements from the Measure metamodel. The metrics used in the transformation will be explained in an upcoming section.

Metamodel for representing measurement data

Measurement data on a metamodel

To have a better vision of the resulting measures we performed another transformation. The metamodels handlers of this transformation are Measure and Table . The resulting model is a generic tabular representation (A table contains rows and rows contains cells). We are now able to collect measurement data for each metamodel of the zoo. But we also want to have a global vision of the measures performed on the entire zoo.

Measurement data on the entire zoo of KM3 metamodels

To do this, we have to consider only the MetamodelMeasureSet elements and merge all the measures from all metamodels.

This step is done with an ANT script which iterates on the zoo and run a transformation which refines the model of measure of one metamodel and merges it with the measures from the previous metamodels of the zoo.

The metamodels handlers for this refining and merging transformation are both Measure. We have two inputs, the model generated by KM32Measure and a second model for storing the measurement data from the entire zoo. For the first iteration, the second model is empty. But next, it is passed as the second model for the next iteration. It is a way to refine and merge data with one transformation and using an ANT script.

Final measurement data representations

Other transformations have been developed from the model of table containing measurement data from one metamodel or for the entire KM3 zoo. The main output formats are HTML and SVG.

We can obtain an HTML file containing tables, by performing a Table2HTML transformation and an extraction.

The same method is possible for SVG, with two possible representations. Bar chart and pie chart with the transformations Table2SVGBarChart and Table2SVGPieChart, followed by an extraction to a SVG file.

Metrics implemented

These metrics are primitives metrics needed for the next metrics:

• Total Number of Packages TNP is the total number of packages in the metamodel. • Total Number of Classes TNC is the total number of classes in a package or the metamodel.

• Total Number of Attributes TNA is the total number of attributes in a class, package or the metamodel.

As we said, these metrics are metrics from UML class diagram. But we can reuse those which do not concern methods, visibility and overwriting. KM3 metamodel contains packages which contains classes and enumerations. And a class can contain attributes and references (composition or association relationships).

• Depth Inheritance Tree DEFINITION. The Depth of inheritance of a class is the DIT metric for a class. In cases involving multiple inheritances, the DIT will be the maximum length from the node to the root of the tree. GOAL. DIT is a measure of how many ancestor classes can potentially affect this class. This metric was proposed as a measure of class complexity, design complexity and potential reuse. It is based on the idea that the deeper a class is in the hierarchy, the greater the number of attributes and relationships it is likely to inherit. GOAL. This metric looks at the quality of the classes use of inheritance. It examines superclass-subclass inheritance relationships • Attribute Inheritance Factor DEFINITION. The Attribute Inheritance Factor (AIF) is defined as a quotient between the sum of inherited attributes in all classes of the system under consideration and the total number of available attributes (locally defined plus inherited) for all classes:

AIF = ∑ Ai(Ci)/∑Aa(Ci)
Where: Aa(Ci) = Ad(Ci) + Ai(Ci) = attributes available in Ci (those that can be manipulated in association with Ci), Ad(Ci) = An(Ci) + Ao(Ci) = attributes defined in class Ci (those declared in Ci), An(Ci) = new attributes in class Ci, Ai(Ci) = attributes inherited in class Ci (those inherited in Ci) GOAL. AIF is defined as a measure of inheritance, and therefore a measure of the level of reuse.

Sample results

This section provides some sample results obtains with ATL transformations with SVG as the target metamodel. Many other result shapes, for example Kiviat diagram could be obtained similarly. By changing the target metamodel, for example XHTML or Excel, we could obtain tabular presentation as previously mentioned.

The length limitation of this paper does not allow illustrating the variety of information that may be extracted in various tabular forms from metamodels. However the first results of this measurement campaign show how easy it is to build a library of reusable measurement transformations.

The two following colour pictures are not of excellent printing quality, but have been included in the paper to illustrate how various model metrics may be obtained in real time, as a result of a simple ATL transformation.

CONCLUSIONS

We are working in an area where we need experimental data to perform research investigations. This has been the initial goal of the AM3 project: setting up an open source repository for models of various types. We have found the Eclipse community and support to be of great help in this. The repository of models is now evolving in different directions and available to the model engineering research community for various experiments.

We have proved that any verification or measurement of a model may be expressed as a transformation in ATL, a QVT-like model transformation language developed at INRIA. This paper has reported on the first metrication campaign performed with ATL on the AM3 zoo of metamodels. This campaign will be followed by many others and has already allowed a deeper understanding of several issues. Among them for example is the issue of metamodel dependent and independent expression of measures.

Figure 1 .

 1 Figure 1. Theoretical aspects of our Global ModelManagement approach

Figure 2 :

 2 Figure 2: Measure metamodel The previous metamodel offer the possibility of organizing sets of measures on different model elements (like metamodel, package, class or attribute). A set of measures owns a type (the model

Figure 3 :

 3 Figure 3: Collecting measurement data from one KM3 metamodel of the zoo A first step is to collect measurement data on one metamodel of the KM3 zoo. We do this with ATL transformations. First a metamodel is selected from the zoo in KM3 format. We inject this model to an Ecore model and use it as the input model of the first transformation. The first transformation input and output metamodels handlers are KM3 and Measure. The collection of the measurement data is done by running the transformation KM32Measure.

Figure 4 :

 4 Figure 4: Collecting measurement data from the entire zoo of KM3 metamodel

•

  Number of Children DEFINITION. The Number of Children (NOC) is the number of immediate subclasses subordinated to a class in the class hierarchy. GOAL. This is a measure of how many subclasses are going to inherit the attributes and relationships of the parent class. • Number of Attributes DEFINITION. The Number of Attributes (NA) is defined as the total number of attributes in a class. GOAL. The number of attributes available to the class and not its instances affects the size of a class. • Number of Attributes Inherited DEFINITION. The Number of Attributes Inherited metric (NAI) is defined as the total number of attributes inherited by a subclass.

Figure 5 :Figure 6 :

 56 Figure 5: Pie chart with a sector for each value of the metric Number of Children for each class

ACKNOWLEDGEMENTS

We would like to thank all the members of the ATLAS team for their help in this ongoing work, and specially Patrick Valduriez, Ivan Kurtev and Guillaume Hillairet. This work has been partially supported by ModelPlex, an IST European project.


Jean Bézivin

Régis Chevrel

Hugo Brunelière

Albin Jossic

William Piers

Frédéric Jouault

ModelExtractor an Automatic Parametric Model Extractor

Keywords: Reverse engineering, model extraction Parametric metamodel, tagged metamodel, dynamic model, MDRE

Building on previous experiments of reverse engineering with the Squeak language, we have designed a new prototype on the DotNet platform that should be able to exploit the full capabilities of the Visual Basic 9.0 language, including the facilities offered for dynamic typing. The objective of this work is to prove that we are able to implement an automatic model mining facility when the system consists of a legacy with good reflectivity capabilities. The initial work presented in this paper comforts the previous results obtained for Squeak and constitute the basis of a reverse engineering development toolkit that is intended to be extended in the coming months.

Introduction

Industrial returns of experience show that software maintenance projects are difficult, especially when the managed projects include different domain programs written by different peoples. Model Driven Reverse Engineering (MDRE) is a powerful possible response. Reverse engineering is an attractive technique to assist the understanding of unknown programs but the lack of fixed standards increases the management effort. Model Driven Engineering (MDE) provides some answer to this interoperability problem by using models as representations. MDE, particularly the Model Driven Architecture (MDA™), suggests using models to represent systems. These models conform to metamodels. MDRE solutions have been already implemented, like (e.g. Modelisoft [6] in the DotNet environment), and are capable to extract models from a system (a program). This kind of work needs a reflexive language that permits introspection, like Smalltalk, DotNet or Java. But these extractions are limited to a specific fixed metamodel and produce static models based on a static point of view of the considered system.

We describe a work which is in process at INRIA in the ATLAS team in Nantes. Our aim is to offer a new solution with a tool capable to extract models from dynamic systems with parametric metamodels. Our approach is to give a decorated metamodel to our extractor which can analyze a program in execution and produce a model conforming to any metamodel. The metamodel is a view definition on the system modeled by the produced model. The decorations will guide the exploration by giving information about the local step knowledge extraction and about the next step discovery.

Another particularity is to implement this solution in the Microsoft DotNet technological space [4] while most of our tools are presently working on top of the Eclipse Modeling Framework (EMF) [5]. We permit inter-exchange between these two spaces by serializing the produced model in Ecore format and by providing an Ecore reader/writer for Visual Basic DotNet. So we can use the Atlas Model Management Architecture (AMMA) facilities [START_REF] Atl | ATLAS Transformation Language Reference site[END_REF] to define our models, in particular Kernel MetaMetaModel (KM3) to define metamodels and Atlas Transformation Language (ATL) to transform models. This paper is organized as follow: section two presents the AMMA platform, principally KM3 and ATL. Section three introduces Microsoft DotNet architecture and Visual Basic. Section four presents some theory about models and metamodels relations and about the role of decorations. Section five defines the Data Structure For Models (DSFM) which defines a basic data structure to represent models and metamodels in memory. Section six describes our actual implemented prototype before section seven presents some ideas for extensions.

Presentation of the AMMA platform

The AMMA platform proposes a complete set of tools for models manipulation. It is composed of four main tools:

• ATL [START_REF] Atl | ATLAS Transformation Language Reference site[END_REF]: Atlas Transformation Language. A QVT-compliant model transformation language based on metamodel definitions and OCL rules. It has a large and rapidly growing user community.

• AMW[3]: Atlas ModelWeaver. A metamodel agnostic tool allowing to build weaving models between any kinds of models. • ATP: Atlas Technical Projector. Defines a set of injectors/extractors enabling to import and export models from/to foreign technical spaces (Java classes, Relational databases, etc.). • AM3: Atlas MegaModel Management.

Defines the way the metadata is managed in AMMA (registry on the models, metamodels, tools, etc.). Visit the Atlantic zoo [2] to get an idea of some global model management possibilities of AM3. All of these tools use KM3 as a common language to define metamodels. KM3 defines a neutral metametamodel. The AMMA platform provides MOF, Ecore and others injector/extractor to KM3 (Figure 2).

Figure 2 KM3 as a pivot

Two of the tools are particularly interesting for our work: ATL and KM3. KM3 provides the main ideas for the construction of our DSFM format which has to represent models and metamodels in memory. ATL allows us to transform a model from its native form to any kind of target metamodel.

Presentation of DotNet and VB

As we say, reverse engineering may be facilitated if we have a reflective language to operate. DotNet introduce this possibility by using a virtual machine to execute program from Visual Basic DotNet for example. The source code is translated to pseudo code, the Microsoft Intermediate Language (MSIL) which is interpreted by the virtual machine, Common Language Runtime (CLR). This pseudo code is called assembly. Figure 3 summarizes the DotNet mechanism.

Figure 3 DotNet global mechanism

Another need we have is to compile a generated source code to MSIL. In fact, exploring a decorated metamodel produces a kind of parser which can really extract information from the system to construct the target model. This parser is generated in text form, a Visual Basic source code. Then, we need to run this program automatically by calling the main method of the produced assembly. DotNet provide code compiler with these two interfaces:

• System.CodeDom.Compiler.VBCodeProvider (framework DotNet) • Microsoft.VisualBasic.VBCodeProvider (Visual Basic API) So, we can instantiate a compiler and run it on a string source code. This operation returns an executable assembly.

What is a model?

We now briefly make explicit the relation between models and metamodels. We say that a model conforms to a metamodel when all the entities which compose the model are related to a metaentity in the metamodel. The association between a class and its metaclass is called the µ link. It is comparable to the instanceOf EMF link but as the vocabulary infers lot of confusion, we explicitly rename it to µ.

In the MDA approach, we consider three levels in the metamodeling hierarchy:

• Metametamodels (M3): define the semantic of the metamodels and itself. • Metamodels (M2): are conforming to M3 and define the semantic of the models. • Models (M1): are conforming to M2 and represent the real world, the systems.

The Figure 4 sums up these concepts.

Figure 4 Relations between models and metamodels

The systems we consider here are programs. But a program is also a model which represents the real world. So we can transform it to obtain the wanted conformance to a specific metamodel.

The decorations define this transformation by specifying the local knowledge extraction and the next step to go. Decorations are like an executable weaving which automatically produces rules. Figure 5 illustrates the decorations machinery.

Model representation

To manipulate models, we need to define a structure which can store these and help us to manipulate and navigate. This is what the DSFM provides. This storage facility is inspired from the KM3 metametamodel and can also load M1, M2 and M3 in memory. Figure 6 presents the DSFM. We have prefixed our classes by DS to distinguish these from other classes. The µ symbol is replaced by the symbol "mu" in the drawing.

The most important entity is DSElement which is encapsulated in DSModel. Refer to KM3 [START_REF] Atl | ATLAS Transformation Language Reference site[END_REF] for more details.

At the implementation level, we added some properties and methods to help navigating the DSFM. Figure 7 focuses on the two major classes implemented in Visual Basic. This figure is generated by Visual Studio from our source code.

Figure 7 DSFM implementation details

We added methods in DSModel to navigate in the model, like getModelElementFromName which gives an element of a metamodel by giving his name (metamodel elements are named and names are distinct). Others, like DSElement.MuName, help to the construction by permitting notably logical µ link instead of physical association. It is practical for M3 construction because the entity can be its own metaclass (cycle).

We try to develop an explicit and elegant syntax by defining methods like DSModel.newInstance DSElement.setValue or DSElement.updateReference that properly instantiate and update model elements.

Global mechanism

Our aim is to extract a model (conforming to an arbitrary metamodel) from the exploration of a system. Figure 8 illustrates this idea.

Figure 8 Model Extractor global mechanism

We now present the behavior of the extractor. We divide the solution in three components:

• MetamodelsLoader: loads decorated metamodel from Ecore files • InspectionEngine: browses the metamodel, extracts information from system and builds out model • ModelsExporter: exports DSFM to Ecore files.

The Figure 9 presents this cut-out. The MetamodelsLoader starts by uploading a KM3 metametamodel. Unlike MDR, we do not need to bootstrap this self reflective model due to the simplicity of this language (DSL). Then we can load a metamodel from Ecore files with correct µ initialization.

First results

Our prototype is a first attempt to implement a general automatic model extraction solution for the DotNet platform, and more particularly from Visual Basic 9.0 code. We have demonstrated the feasibility of the decoration process by producing an assembly to Visual Basic extractor. The generalization to a parametric metamodel is explained in the next section. In summary, we make an injector to our technical space by using decoration engine principles.

First we define a simplified Visual Basic metamodel and we establish the mapping for information extraction from assembly. Decorations actually copy this mapping. We just consider static view for the time being in optic to test our DSFM and become familiar with the tools we need like CodeProvider (compiler). Figure 11 illustrates the actual implemented solution.

Figure 11 Actual implemented solution

We realized a complete simplified chain by loading a decorated metamodel from Ecore files (Figure 12), producing an executable extractor by exploring the metamodel, compiling the resulted code, running it on a static assembly and, finally, generating a model which represents the system and is conforms to the metamodel (Figure 13). This metamodel is defined in KM3 and is exported to Ecore format by the existing tools. The DSFM is capable to store the metamodel and we can easily navigate it.

Figure 13 Prototype extract model from decorations compilation

The target model is generated from code, resulting from decoration discovery and following the organization given by the metamodel. For an element, the first word represents the metaclass name by navigating the µ links and the second is the first string attribute we find, if it exists (assuming that it is the name). It illustrates that the conformance is assured by the prototype and that the attributes are valuated. We now just have to export the DSModel to an Ecore file with the ModelsExporter.

Extensions and Future Work

The prototype has been tested on a given metamodel and for static systems. We suggest some realistic solutions to extend it to a parametric metamodel guidance extraction and for dynamic system execution snapshot. Furthermore, we want to formalize the conformance test for the out model by implementing a conformance checker component.

Parametric metamodels

The first improvement we want to do is to extend the solution to many metamodels. We use our actual prototype like an injector to our DSFM space and we transform the resulted model to a wanted conformance model using transformation language like ATL. Either by develop a decoration DSL inspired by ATL or by implement an engine for ATL in DotNet, then the decorations become weaving description. We privilege the second solution to integrate this realization to the actual AMMA platform. Figure 14 illustrates the goal.

Dynamic systems

We want to capture dynamic systems models by tracing the activity of the processes, like trace out the constructor methods invocation for example. There are two possible approaches: with intercession mechanisms, we can modify marshaled system comportment by adding a listening protocol, but it is not always admissible, or by extending the virtual machine to capture system events before transmitting these to the CLR, like the Visual Studio debug environment. The second proposition is better because we do not have to touch to the system, which is more correct, but very harder to achieve. Then the target model could be continuously alimented by the virtual machine extension. So it is possible that we need a representation to define infinite model structure and construction.

Conformance Checker component

For the moment, we strongly believe in the correctness of the extraction of our ModelExtractor, but we think that is will be useful to have a specific component to check the precision of the conformance construction.

We want to implement a ConformanceChecker which will control the correct conformance of the model step by step or at the end of the execution.

Conclusion

We have obtained very encouraging results with our first prototype. The feasibility of the global approach has been proved and we already have ideas to extend our solution. We will concentrate our effort on two ways: principally we aim at implementing an ATL engine for Visual Basic and also trying to develop a capture environment to establish dynamic snapshots. Many problems will then rise, like distortion with time stamping or the risk to influence systems comportments by studying these in real-time.

Ackowledgements

Figure 1 AMMA

 1 Figure 1 AMMA Platform overview

Figure 5

 5 Figure 5 Decoration general mechanism

Figure 6

 6 Figure 6 DSFM conceptual structure

Figure 9

 9 Figure 9 ModelExtractor components cut-outAll of these components use the DSFM to represent and exchange models whatsoever the level. The heart of the solution is the InspectionEngine. It runs in several steps presented in Figure10.

Figure 12

 12 Figure 12 Prototype loads metamodel from ecore files

Figure 14

 14 Figure 14 Extension to a parametric solution

We hank all the members of the ATLAS team that helped to implement this approach, and particularly Ivan Kurtev, Freddy Allilaire and Marcos Didonet del Fabro. This work has been partially supported by Microsoft Research, Cambridge and by the ModelWare, IST European project 511731.


Keywords:

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction of Computers in Primary Schools in Norway -From Experiments to Implementation

Introduction of Computers in Primary Schools in Norway

-From Experiments to Implementation

Introduction

From the 1960s till the mid-80s computers in education were the era of enthusiast teachers and single experimental schools. But around 1980 there was a shift in policy as computers became more widespread in society.

In 1985 a revised version of the curriculum guidelines for primary and lower secondary education was launched -M85. The impact of computers was one reason to present a new policy, introducing computers as part of the curriculum. The year before the government established a Ministerial Task Force (Datasekretariatet) to speed up introduction of computers in education. Substantial budget resources were allocated to the program's experimental work, including research and evaluation of the initiative. The Task Force ran a wide range of activities and sub programs till it was closed down in the early 90s when the implementation phase started. In this period several White Papers on computers in education passed the Parliament, discussing the policy and strategy of experiments and implementation. The Task Force was empowered with wide proxies both on policy strategies and resources. The initiative was followed by research programs of classroom practices, software initiatives including an evaluation of national policy in the field.

This experimental phase included several elements among which some turned out to become quite controversial: 1. Describes responsibilities of actors like: National bodies, universities/ colleges, regional/local authorities. In 1984, a milestone was set when the Parliament approved White Paper no 39 (1983/84), a programme of action to introduce computer technology into schools through experimental activity in selected areas and schools. The very clear purpose was to prepare for the introduction of compulsory IT in Norwegian schools. The urge of doing this was so strong that the compulsory introduction did not wait for any results from this programme of action before information technology, in a broad sense, was made a part of every subject (integrated) in primary and lower secondary education. In 1985 a preliminary edition of a new, revised, curricular guideline was introduced. In 1987 the final version was approved by the Parliament, one year before the programme of action was fulfilled, and final evaluation results were published. The revision where IT was included in the new curriculum guidelines announced the information age and represented a broad and overall approach. The Plan of Action represented a narrow, or a project approach, to gain experience in use of computers in education. In this chapter I will concentrate upon White Paper no 39 (1983/84) and White Paper no 24 (1993/94). There are several reports to the Parliament in between which will not be dealt with here.

The Task Force (Data Secretarial) period 1984 -1988

1984 -1988 can be named as the Data Secretarial (DS) period, but it must be underlined that there were activities throughout the school system not linked to the programme. The programme in general did not address all schools and teachers but was limited to experimental schools only. This caused some stress among teachers that were rejected assistance by the Task Force. Schools in general should be served by the National Advisory Council for Primary and lower Secondary Education, the National Advisory Council for Upper Secondary Education and the National Advisory Vocational Training in Working life. The tasks of the National Councils were to handle educational matters within their field, including professional developments and projects. They enjoyed a relatively independent role within their defined area and were considered to supply the education system with educational expertise and knowledge.

IMTEC (International Movement toward Educational Change, http://www.imtec .org/english_version/ ) in their evaluation of the programme found a system-conflict between the National Councils and the Task Force. It seemed clear that the project model caused some stress throughout the school system. The reason might have been unclear, or lack of, communication between central actors when it came to distribution of responsibility and tasks. This is in spite of intentions of close cooperation explicitly outspoken in White Paper 39 (1983/84). The Task Force was established in understanding with (p 49), and should co-operate closely with (p 39), the National Councils. The National Councils should by and by take care of most tasks (p 39). Access to available resource in the field is of course an important reason to conflict as well, but it is likely that the Ministry did not take enough care of its' own system understanding, and therefore was not able to sort out and distribute the tasks in a reasonable way.

Introduction of IT in general in schools lies under the Ministry with the regional School Directors and the National Advisory Councils, and was not within the mission of the Task Force. Their work could rather be defined as an innovation programme, preparing reform. Innovation in this case can be defined as renewal, or "a considered effort to improve practice related to given goals" (Dalin 1986: 35). Results from the programme were open to a broader educational public when it came to programming courses, development of educational software, and in providing the schools with educational software.

The main elements in the strategy outlined in White Paper 39 (1983/849) were a programme of action carried through by a task force, and evaluation of the programme by an external agency, IMTEC:

1. A project strategy approach with experimental activity at selected areas and schools. 2. There were some hardware demands, specifying standards of graphics, operative system etc. To equip the project-and experimental-schools with sufficient hardware the Ministry of education, through the Task Force, paid 75% of the costs. Only two computers, TIKI and SCANDIS, were approved for use under the programme. 3. Access to sufficient software was defined as one of the most important tasks and software development and testing was given high priority. The software was made for the two approved models. (Schools in general which were free to buy whatever computers they wanted had to stick to TIKI or SCANDIS if they wanted this software.

Another field of high priority was teacher training or competence

development. This included building of networks, mutual co-operation between schools of same and different kind, institution within and outside the school system and establishing national resource centres for the whole school system. It was stressed that implementation of computers had to support the major values of education in Norway by preventing emergence of new class divisions; social or gender differences, support critical thinking etc. Furthermore the programme should develop the education system's own expertise, stimulate trial teaching and debate, and stimulate collaboration across the school system, with homes and with trade and industry. The technology should be used to seek better ways of teaching and learning, and mentioned elsewhere; special education was given priority. To stimulate experiments, collect, systematise and disseminate information on the experience in this area were also to be done.

The project approach was based on schools with previous project experience. Participation in the programme was supposed to be on a voluntary basis. To be accepted as an experimental school the whole staff had to support the application, which the School Board then must approve, because local support and local resources were needed. Project schools could participate on a narrower basis, with just a few teachers. In this way accountability and ownership should be secured. The evaluating agency had several contacts with each experimental school, and to some extent had a kind of action-research element as project strategies were introduced through the first surveys. The project-leaders were made aware of important issues to discuss with their colleagues. To some extent schools may have felt the evaluation teams' survey as clarifying, and as a support to their projects. White Paper 39 (83/84) does not say that this was an intention or a purpose of the evaluation programme, a role of IMTEC. The Ministry seems to be aware of the need of guidance (CERI -report 1987: 22):

"A programme of action must have the character of a set of government measures which can provide guidance in the desired direction for the development in different areas of the school's activity and within all branches of the school system." And there was a process for the evaluation between the Ministry and IMTEC before the programme started (Report no. 15 1989: 17). IMTEC underlines as important that:

"The actual or perceived assumptions behind a program will often tend to restrict the possibilities of development. To conduct a genuine dialogue on the structural aspects will therefore contribute to establishing greater freedom of action, thereby increasing the possibilities for the project to provide results as originally envisaged" (ibid.: 22 -23). The plan of action had both an element of top-down approach and a bottom-up strategy. The programme had defined their goals and aims nationally in White Paper 39 (83/84), but the schools by invitation defined their own projects, processes and goals. The Ministry itself expresses this in this way according to the CERI -report (1987: 13):

"What seems to emerge is that an action programme which is either based solely on a central controlled model for development, or alternatively on a completely decentralised model, would have little chance of success." An action programme, however, does not have to be either completely centralised or solely decentralised. On the contrary, both elements can be represented in an action programme. The Ministry itself describes such a model (top-down combined with bottom up) in a White Paper on Research and Developmental work (No. 79 1982/83). Locally managed projects need to be more emphasised, with a growing activity as a predicted result. However, there can be two different kinds of developmental work: i) locally initiated and managed and ii) centrally initiated and guided developmental work. Information technology was defined as a national field of priority, which is centrally, initiated projects, but they were open to locally managed projects. In the CERI-report 1987, page 13 this is taken into account in this way:

"On the other hand, the development will demand so much concentrated effort in in-service training and at the same time extend regional and central measures which ensure quality, continuity and learning experience across the boundaries of different kinds of schools and different regions." Without going into it here, it does not seem that all schools were aware of their relative freedom in defining their own projects. I participated in some seminars, representing a school owner and witnessed several requests for more detailed, centrally defined instructions both on content and processes of projects. One of IMTECs' conclusions points out that maybe the most critical factors for success is the school's ability to master the trial process (IMTEC, 1987: 78). The panel at the closing session of the IFIP working conference 'Exploring a new Partnership: Children, Teachers and Technology' made about the same conclusions stating that introducing IT faces the same challenges as every other innovation project, there is nothing special about IT (Røsvik, 1994: 290). The challenge is to tackle teaching and learning strategies in an appropriate way. We will not go into the running of the programme or special details concerning courses, software developments etc. This will just be mentioned as below.

Fields of priority were special education and the development of adaptable hardware and software, special keyboards etc. Vocational training was also focused upon as the Ministerial Task Force was engaged in developing software, hardware and suitable technology to increase the level of competence in the field. The main project was MI-2000, mechanical industry towards the year 2000, developing hardware and software for the mechanical line in vocational education. Computer assisted construction and manufacture (CAD/CAM) for models and machinery was part of it. During this period the Nordic countries established a close relationship in the field, still existing, exchanging software by special arrangements and by publishing pedagogical and methodological experiences in a mutual organised educational magazine. The Task Force was very active in participating at international conferences and congresses presenting the programme, and promoting educational software for sale. Programme development was initiated through ministerial design courses (starting out as Norwegian but later became Nordic courses) and by buying and distributing other software developed by individuals or small private firms. In total the Ministry could list close to 100 programmes, mostly educational software but also some software tools.

Even though the programme period of the Task Force came to an end in 1987, its work continued till 1 st August 1990. In some respect, transferring the personnel to the Ministry extended the period of the Task Force. The programme itself including the work of the project schools was ended. Final evaluations of the Task Force were conducted by IMTEC and OECD and presented to the Ministry of Education and the Parliament in 1988. Based on the evaluation reports new initiatives were suggested, referred below in the next chapter.

During these years there were a number of teachers who were eager to introduce use of computers in their own teaching. In 1986 some of these started to establish an educational computer society and in 1987 the Norwegian Pedagogical Computer Society (NPeD) was founded. The aim was both to address policy initiatives to introduce computers to schools and to run practical help and courses for teachers in the classrooms. Special education was given priority and had a focus in courses and policy initiatives. During the first years the board had members representing special needs programmes. Another purpose of the society was to inspire teachers by organising study trips to Denmark, in cooperation with their sister organisation Datalaererforeningen. The founding chairman in Norway was inspired by the Danish organisation when joining their study trip to Boston and WCCE 1985 in Norfolk (USA). During the first year NPeD organised several conferences where national policymakers and politicians were invited to present new initiatives and to be challenged on lack of initiatives and given input by classroom teachers. However, most focus was given to hands-on courses for use of computers in the classroom, raising pedagogical challenges as well as subject issues. The members of NPeD were computer pioneers and teacher enthusiasts that had high expectations for computers in education and wanted to push the development to improve and modernize education for their students, preparing them for the immediate future.

Intermediate Period 1988 -1993

The second phase started when the plan of action was fulfilled. White Paper 37 suggested continuing the work of the Task Force by establishing a new administrative unit called DATOPP. The experiences of the project schools were to be disseminated by the National Councils and regional bodies. Finally it was suggested that the ministerial capacity for strategic planning should be strengthen. Special education and vocational training had been emphasised during the project period and this work should also be continued. But the Parliament did not approve the establishment of a new unit, and this led to a situation that meant that the Ministry had to continue the work within the existing organisation. The personnel of the Task Force continued working, within the Ministry.

During the period 1988 to 1993 several of the field relevant White Papers were passed to the Parliament. They will not be mentioned at all or commented upon in this paper. In the first part of this intermediate period, 1988 to 1990, there were some organisational changes within the Ministry of Education. However, the central persons of the Task Force continued working with IT programmes, supporting software development and some other limited programmes, directly or through other national educational bodies (National Councils, regional school programmes etc.). The National Councils were closed down, and personnel and tasks moved into the Ministry. There had been tensions between the different parts of the national organisation for some time.

A third phase was introduced by White Paper number 14 (1989 -90) formulating a plan for information technology for school and training for the period 1990 -93. During these years some of the earlier initiated programmes were followed up. Some of these programmes must be mentioned especially, namely an ambitious project of distance learning through telecommunication: MI2000 and PEGASUS, giving birth to WINIX. Great expectations were put upon the WINIX concept, a sophisticated software concept handling telecommunication in an advanced way. MI2000 was developed within the vocational part of the programme and attracted attention from outside the school system. This could also be said about some other programmes that were presented internationally, and distributed within the Nordic programme of cooperation.

Without going into details, the WINIX-project turned out to be a stumbling stone for the Ministry, almost costing the Minister his seat. The media paid growing attention to critical voices attacking the concept and the Ministry's handling of it. In the end the Parliament demanded a special report on 'Certain sides of the Educational Ministry's IT-programme', also named the WINIX-case. The mixture of ministerial administration, business and policy came to an expensive end, leaving the Ministry of Education an unpleasant bill to pay. In spite of lots of good and useful work done by, or assisted by these programmes, the reputation was severely damaged by this case. Some of those involved were even reluctant to tell that they participated in the programme.

This was the background of this White Paper on information technology in education. The words of the Minister at the conference in October 1993 can be grasped in a deeper way being familiar with this political scenery. It makes it even possible to understand why this White Paper over and over again underlined that IT should be 'normalised' and that no 'special' money would be required or paid, to carry out this new programme of action. But it could not deny questions to be raised if there was a programme; with no extra money, and if the interpretation of the 'normalising' programme was that no special focus should be given to IT in education. Some of the programmes that still kept running were stopped, before, or without, any substitute programme introduced. Other programmes would no doubt have profited from some financial input to be more widespread, known and used by Norwegian schools. Once more, however, it must be underlined that the Minister heralded that a plan of action was to be worked out during the year to come. The interpretation of intentions and consequences of White Paper No. 24 (1993-94) might turn out to be different from this described scenery of withdrawal of ministerial efforts and recourses.

Continuing Initiatives 1993 -94

The intention of this White Paper was first of all to report from the previous programme of action ; secondly to answer questions raised by the Parliament. Finally, and what ought to be the most interesting part, was presentation of strategies for further work within the sector of education. This strategy should have been the contribution of Ministry of Education to the National Plans of Action concerning IT; completing plans of action of trade and industry, and public administration. A plan like this had been awaited, and announced, for more than a year when the Ministry of Education finally informed that there would not be a similar plan of action for information technology in education. White Paper no. 24 was launched and produced very fast, in what seemed to turn out to be the normal way for this Minister. The writing process started in October 1993. On the 24 th of October the Ministry invited about 100 people from different educational and information technology milieus to a meeting where the Ministry, with the Minister in front, announced their intentions about this White Paper and the production schedule. They invited the participants to comment upon the outlines of the paper in the meeting, and eventually to contribute with proposals in writing. On the 14 th of January 1994, White Paper no. 24 (93/94) was released, in print and by Internet, immediately accessible to everybody. By the 20 th May the White Paper passed the Parliament, and the Ministry, co-operating with the Norwegian Computer Society, had a one-day conference presenting the White Paper and further plans to work out a plan of action. In this process the Minister invited everybody to participate in the process by giving his e-mail address. Later the Ministry confirmed that they wanted to have an open process, willing to listen to professional groups such as the Norwegian Educational Computer Society and the Norwegian Computer Society.

A main conclusion was that the work concerning IT in education was to be financed according to the ordinary administrative levels. The Royal Ministry of Church and Education prescribed that there was a normalisation of IT in education, with no extra money, no dedicated people responsible for IT at any level, if not the institutions will give priority to the field, which some will do and some will not do. The national level worked out plans and guidelines, and thereafter information and advice. Special attention might be paid to IT in education in this respect, but mainly it seemed that the Ministry would rely upon institutions, universities, and municipalities to follow up and keep in line, being responsible. But what if a municipality failed, overloaded with other local tasks, like taking care of the elderly? What if a teacher college continued to be out of line? A national plan of action ought to consider questions like these. To follow the situation in the schools the Ministry developed a system of information-collection, and also did some special investigations.

The normal management model had to be the basis in every educational matter and any plan of action. Responsibility was distributed to the different levels, where there should be a system of support and development, to spread information and link specialists, specialists and schools, and projects together, taking care of the headmilieus and facilitating international co-operation and development. With no extra money, this was to be done with 'normal money' within ordinary budgets. Lifelong learning for individuals is based on a lifelong learning society. The Ministry of Education would execute this task through its administrative body, National Learningaid Centre (NLS).

Throughout the chapter on practical organising (chapter 9) each section had a state of art and an initiative paragraph. The initiative paragraph should give instructions or information on actions. Mostly there was a list of aims, giving little information of actions. According to the Ministry's' presentation of the White Paper on the 24 th of May this was intentional, and the Minister, therefore, heralded that a plan of action that was to be published within a year.

The White Paper also reported to the Parliament on previous ministerial work and projects on IT in education, and presented outlines of future plans. It did not intend to prescribe resources or give any details of projects or plans of action. This would be a ministerial work and responsibility. The Ministry seemed open to ideas and proposals from professionals and others who wanted to contribute to a national plan. There were many open ends and issues to be considered and decided upon.

The main keyword in the White Paper was normalisation. This meant normal distribution of responsibility and work between the different levels of educational administration, according to what was normal in other educational matters. There would be no special ministerial task force. There would not be any extra IT resources, money of personnel. There would be no special software or hardware development conducted by the Ministry of Education. The change from the Data secretarial period was clear and significant. The ministerial culture signalled to be reversed from the view of IT projects as extraordinary to the ordinary. It was back to normality. But the Ministry, underlined by the Parliament, wanted to pay attention to IT in education to make sure that education kept up to date. There was an understanding of the role and importance of IT in society, and education. The will to be active at a national level was still considerable. A plan of action was to prove that. There could then be some final questions: What a normal allocation for developmental purposes on IT in a modern society would be like? Could a growth in resources to development and innovation be expected? Was it likely that municipalities would, and were be able to finance such development and innovation programmes? Would there be new initiatives for innovation and development or to support existing milieus, network building, in this respect within and outside formal institutions?

The intentions and basic principles of this White Paper seemed in some respect to be sound and reasonable concerning what should be done. But looking into how it should be done it was not so clear, what in fact was to be done, if anything would be done. The education minister was considered to be a man of action, good at slogans. He had put forward major structural reforms changing the school system from kindergarten, primary and secondary education to higher education. When it came to ICT, however, initiatives and actions were slowed down.

The municipal economy, however, was tightening. A growing elderly population required an increased share of public care and money. The municipal financial order in Norway is mainly based on lump sum allocations from the state. However, the municipalities do not have full freedom in economic priorities. The Parliament from time to time may give attention to some special fields or tasks, offering dedicated resources to, for instance, elderly care (more and better institutions, more personnel), provided that the municipalities are spending an equal amount to the tasks. During the nineties the task programmes have been elderly care and school reforms etc. Such special reforms unbalance the municipal budgetary systems, reducing the power of local authority to set its own priorities. Still, priorities are to be done, even if it sometimes is mostly focused to get hold of state-money. The educational system might consider IT to be as important as it was in society, and act upon it, but within given economical budgets. The point here is that White Paper 24 (93/94) or state budgets didn't offer extra, dedicated resources for IT in schools which meant that this programme had to compete within ordinary municipal budgets.

A plan of action on IT in education should reflect and answer the challenge in a proper way. The Norwegian plan of action on IT in education was to be based upon White Paper 24 (93/94). If, or to what extent, it would meet future needs and challenges was to be seen. The indication, however, was that no extra money could be expected. The strategy outlined, in some respect, seemed to stress harder that this White Paper represented a different course then that from the Task Force, the one that lead to WINIX-case. In a way one could be reminded of the, at that time, on-going transition of Eastern Europe, where politicians for some time had been more clear about the change of policy, making it different from the previous regime, then about what to do. The ingress of the White Paper by the end stated this philosophising on IT (KUF 1995, IT in Norwegian Education. A Plan for 1996 -1999, English version: 4):

"It is, therefore, becoming more and more difficult to imagine how we could manage without it, and to imagine how far it will take us. But it is because of this very development, and the speed at which it is taking place, that it is so essential both to increase the knowledge of the opportunities and our skill in availing ourselves of them. It is of paramount importance to use the learning opportunities which information technology provides, and to see that it creates a stronger sense of community not wider gaps." It was not possible to tell any future results for sure. The Ministry might follow up the stated intentions put forward in the White Paper, but what this was to be seemed quite open ranging from special initiatives, to nothing especially. What would count in the end were what operational steps that were taken, and the force of these actions. Some of the plans and guidelines in this White Paper seemed unclear about concrete actions as well as willingness of central authorities to invest, set resources aside to promote IT developments in education. The main impression though, was that there was both an understanding of importance, and a will to act according to the intentions of the White Paper. The intentions and will seemed present, but the ability was uncertain both concerning resources available and the concrete strategic steps to be taken. It was considered to be a challenge to make the whole school system able to deal with IT in a constructive way. It was supposed by many that this would request a proper way in allocating resources, in supporting and stimulating innovations, in disseminating experiences and knowledge to make the implementation of IT support learning. Machiavelli the famous medieval counsellor said something like: "Nothing is as dangerous as initiating change." In this respect it could be added and changed to: "Nothing is as dangerous as initiating change, except, not to do it."

Table 1 : Overview of white Papers on IT and their focal points

 1

	White	Curriculum	Focus	Suggested initiatives
	Paper/Plan
	No. 39	M74:	1. National	1. Ministerial Task Force,
	(1983-84)	non-obligatory	programme.	evaluated by
		subjects:	2. Experiment: 'whole	IMTEC/OECD
		Technology	schools' project and	2. Experimental schools:
		(Computers not	limited projects	21 schools Projects: 20
		mentioned)	3. Software	schools.
		Media	development, and	3. Almost 100 educational
		knowledge: TV,	import for	software programmes.
		film, newspapers	translation.	4. Conferences and
		etc. (Data,	4. Competence	courses. Design and
		computers not	building on	methods. Reference
		mentioned)	technology and	groups.
			methods, co-	5. Special software,
			operation across the	applications and
			system.	hardware (switches
			5. Vocational/ special	etc.) 6. CP/M-system
			education had	chosen: and within the
			special attention	program, brands: TIKI,
			6. Hardware: chosen	Scandis
			to make all software
			work.
	No. 37	M87: Computer-	1. National	1. Turned down by
	(1987-88)	/media	developmental	Parliament, Task Force
		technologies	centre -DATOPP	continued its work.
		included in	2. Dissemination of	2. Regional
		general part:	results gained at	administration,
		School in	experimental	Ministry council-
		Society, and	schools/projects.	bodies: New Projects,
		Learning	3. Software	conferences/courses.
		Environment.	development.	3. Software programme
		In subjects:	4. Competence	continue.
		integrated	development.	4. Teacher Colleges
		approach.	5. Vocational/special	critical factors.
		IT-themes	education	5. Software/application
		within: science	6. Evaluation of	projects.
		and social	programme 1984-	6. IMTEC and OECD
		science.	88	evaluation Presentation
				included.
	No. 14 and	M87	7. Permanent structure	1. Task Force, Ministry
	42 (1989-		for	bodies, intro and
	90) The		experiment/develop	implementation of IT.
	latter		ment work -and	2. Projects, competence
	supplement		dissemination.	centres