Lenira Haddad

The two faces of Integration: integrated systems of early childhood education and integration of ECEC services within Education

Introduction

Early Childhood Education and Care (ECEC) is on the policy agenda and is a public concern in most industrialized countries. Its value and its multiple roles in society are strongly marked. However, unlike primary school or other levels of education, which have clear goals and a relatively homogeneous form, ECEC's policy and programs encompass a wide range of understandings and programme implementation.

The state management of childcare and preschool education has traditionally been separated into welfare and education, each having its own programme funding and administrative arrangements. Such split systems have been the subject of critical discussion since the 1970s, with the debate towards an integrated approach to early childhood care and education (ECEC) intensifying following the work of the European Commission Network on Childcare in the 1980s and 1990s, and OECD thematic review on ECEC between 1998and 2006. Some countries have sought mechanisms to overcome the inconsistencies of split systems by either setting up intersectoral coordination mechanisms or integrating the responsibilities for ECEC within a single sector. From the 1980s, and more intensively in the 1990s, countries started to move their services towards education 1 . Are the premises that shape an integrated approach model to the previous model of childcare and preschool education the same that motivated countries to integrate all ECEC services within education? This paper intends to discuss this key question by arguing for the existence of distinct movements regarding integration: those towards shaping an integrated approach to childcare and preschool education in general, and those bringing those two areas within education.

In my previous study [START_REF] Haddad | An integrated approach to early childhood education and care[END_REF] I argued that world events such as the Cold War, the Western Cultural Revolution of the 1960s and 1970s, and globalization raise new pressures, which create new value-based tensions for societies to solve, revealing what Cochran calls "pattern of change" once they transcend individual countries. While the Cold War ideologies caused a split in care and education, and the "Western cultural revolution" created a momentum towards integration, unifying educational and social objectives, Globalization forces have restrained the move toward unified services, by tending to minimise government's participation. In this paper, I shall argue that while an integrated approach to early care and education was nourished by the counter-cultural revolution of the Sixties, integration within education has been pushed by globalization.

An integrated approach to ECEC as an expression of counter cultural movements

1 The project Learning and Caring Together [START_REF] Kaga | Caring and learning together: a crossnational study of integration of early childhood care and education within education[END_REF] identifies 15 countries in which ECEC is integrated within education: Iceland, New Zealand (1986), Viet Nam (1986), Spain (1990), Botswana (1994), Brazil (1996), Slovenia (1996), Sweden (1996), England (1998), Jamaica (1998), Scotland (1998), and Norway (2005).

The call for an integrated approach to ECEC is a social phenomenon, a demand from civil society in most industrialized countries undergoing deep changes requiring new childcare arrangements, in which the women's movement played a special role.

The protest movements of 1967-1971feminist, black power, student, hippies etc.-is referred by Morin (1986, p. 165) as a "western cultural revolution", as they problematize in depth within the Western society a model so far uncontested and implicit of "white, western and virile superiority", which shook a system, a civilization, a culture and a society. While, in part, the countervalues that were opposed to the contested values, such as nature, love and peace, are culturally female, on the other part, they amplified an invisible movement; a pre-silent revolution that fought in the female universe and that unleashed a series of changes in the life and role of women in society. For this reason, the author considers the women's movement as a contemporary phenomenon that has placed more fundamental problems of science and politics on man.

Indeed, the global feminist movement played a unique role in the revision of the meaning of day care centre (crèche) by associating it with issues such as maternity, paternity and changes in the domestic arena like gender norms and roles. Moreover, the feminists challenged the idea that childcare services should be restricted to disadvantaged families or poor working mothers.

In many countries, the women's movement played an important role in creating new possibilities for extra parental child socialization, opening up a new concept of childcare -with professional and educational components, which met the child's needs for care and education as well as the social, occupational and family needs of women. This new conceptual framework, encompassing the social and educational dimensions, is one of the seeds sown in the development of what I have called integrated approach to ECEC (HADDAD, 2002, p. 22).

One important observation is the type of services demanded in the context of social movements. For example, in Brazil, the women were fighting for the rights for day care centres (crèches) and that was what was presented in the banner among the crowds. It was probably for the structure these services usually provided: full time, extension of age range (including spaces for under 3) and volume of services (such as resting and feeding). These components shape this type of institution as a solid mechanism of family support, making possible the reconciliation of paid work and family responsibility. Therefore, the linkage of these services to ministries related to family or child matters, which was the majority pattern in most industrial countries. There is no evidence in the literature of the development of day care centres (crèches) under the ministry of education during this period. It suggests that the educational system has not always been able or willing to answer the demands for crèches, which was circumscribed by issues of family life. Some countries were more sensitive and responsive to answer the demand for childcare in a more consistent way, such as the Scandinavian countries and came out ahead with the consummation of integration of childcare services and kindergarten. Although not coordinated, these services were already linked to the social welfare ministry.

The qualitative leap from the past was the recognition of the multiple functions of ECEC, including, other dimensions of human existence not always taken into account. The promotion of child development in all aspects: physical, affective, moral, spiritual and intellectual; the well-being of children and their right to a safe, pleasant, joyful and stimulating atmosphere, as well as new opportunities for relationships with other children and adults; the possibility for parents to combine professional and family activities; the promotion of equality between men and women; and the optimization of the parents' ability to fulfil their parental roles are some of the dimensions that can be cited.

Childcare began to move out of the domestic arena and became considered as an important social means for promoting human development to be guaranteed by public authorities. The work carried out by the European Community Network on Child Care (1988)(1989)(1990)(1991)(1992)(1993)(1994)(1995)(1996) and the OECD Starting Strong project (1998 and 2006) contributed to this debate.

Established in 1988 and committed to gender equality, the EC Network on Childcare encompassed a wide range of issues correlated to ECEC services such as parental employment, parental leave, men as carers and childcare in rural areas. The Network's concept of 'child care' was broad and included the need for employment and the upbringing of children to be combined in a way that promoted gender equality, the best use of parents' skills and abilities and the well-being and development of children (EC Childcare Network, 1992, p.6).

One of the main evidences of the state of childcare services was the split system. The majority of the member states' provision came under the responsibility of two systems: welfare and education. Lack of coherence and inconsistencies between the services offered led to uncoordinated services and overlap of public responsibilities as well as affecting funding systems and admission criteria. Publicly funded services for children under 3, which were often dealt with within the welfare system, were low in terms of supply and offered a lower level of skilled professionals, work, and pay conditions, when compared to the services for children over 3. The latter, generally linked to the educational sector, offered greater availability but with shorter opening hours.

The 1996 EC Childcare Network report took another important step forward towards integration. It focused on the volume of services offered arguing that critical dimension could not be reached by simply counting the number of children and places available in each establishment. Greater availability, daily and annually, as found in the services linked to the welfare systems, was recognised as more in tune with the needs of families and working parents compared to those linked to the education systems. The report was critical of the failure of the education system to take into account the needs of working parents and care for school age children.

As a conclusion, the 1996 Report stated the difficulty to justify the "current" division between education and welfare systems given the recognition of the double pedagogical and care functions.

The development of a coherent and integrated system of services goes beyond issues of structure and organization. It deals with the concept of services -who and what they are for. A coherent and integrated

service should be more able to adopt a holistic approach to the needs of children and their families, recognizing the breadth and interconnectedness of these needs, and the importance of developing an approach to meeting these needs which is flexible and multi-functional (EC Childcare Network, 1996, p. 134-5.).

Created under the premises of equal opportunities for men and women, the EC Network generated an idea of integration that has as a central aspect a joint attention to the needs of children and family. This conception asserts multiple functions to ECEC. While encompassing and going beyond the needs of working parents and children's learning, it also involves a new attitude towards the education of young children. Consequently, the transfer of services to a single ministry was not enough; a redefinition of its goal and structure towards the accomplishment of its multiple functions was a necessary condition.

Several of the premises established by the EC Network on Childcare remained as references in the OECD thematic review launched in 1998. One reason, as pointed out by Mahon (2011, p. 84) could be the collaboration of many members of the Network for the review, including its coordinator, Peter Moss. Moreover, OECD's Starting Strong project was headed by John Bennett, who had been deeply involved in the UN Committee on the Rights of the Child, while in charge of UNESCO's Child and Youth program.

The adoption of the terminology Early Childhood Education and Care (ECEC) was a deliberate option to emphasise the fact that 'care' and 'education' are inseparable and to support the view of 'an integrated and coherent approach to policy and provision which is inclusive of all children and all parents, regardless of their employment or socioeconomic status' (OECD, 2001, p. 14). Therefore, OECD's Starting Strong programme assumes an inclusive approach towards human rights with implications for policy and programme implementation. First, children are seen as a 'social group with rights', and not just as dependents on parents or as primarily in need of childcare to enable their parents' employment' (idem, p. 127). Second, ECEC policies are considered 'part of a system of wider supports to promote the well-being of children and families' (idem, p. 34). Great consideration is given to the potential of ECEC to support parents in conciliating work and family responsibility as well as to promote gender equality. This approach emphasizes the close link between ECEC and parental leave policies as well as the socialization of children in both rural and urban areas. The broader role of ECEC is defined as a 'place for children in their early years to socialise and learn through their relationships with other children and other adults' (idem, p. 41). The review acknowledges that it is important for children to possess skills and learning strategies for school but is critical of the view that they need to be prepared for school and the future.

The second comparative report on the thematic review on ECEC (OECD 2006) evaluates the challenges of ECEC policy-making and service coordination, and restates the broader ECEC policy view that was concerned with not only providing education and care to young children, but also with women's and children's rights. The report indicates that integration under one ministry brings a clearer policy vision in ECEC and more effective funding and management of the system. Neuman (2005, p. 134-5) calls attention to important political and philosophical issues raised by the decision to integrate all early childhood services into the national education system. One concern about bringing together some areas of responsibility is the marginalization of child welfare, health and other services from ECEC, making coordination with such services more challenging, and the exacerbation of coordination barriers with non-education sectors. Another concern is related to the loss of early childhood traditions and practices to a dominant schooling model focused on a narrower set of academic concerns and the erosion of specific pedagogical pre-school methods. While institutional positioning of ECEC within the education system may strengthen its political status with regards to national policy, it may lose some specificity vis-à-vis primary education and policy may become less distinctive.

These concerns are embodied in the term 'schoolification' to express what can happen when early education adopts the knowledge transfer model of primary education and is conceived of as a 'junior school'. The term encompasses a combination of classes organised according to age; adoption of contents and methods of primary schooling with stress on literacy and numeracy; scheduled activities planned mostly indoors; little time left for free play, choice of activities and outdoor discoveries. In this model, teachers are trained predominantly in primary education methods and have little or no certification in early childhood pedagogy (OECD, 2006, p. 62).

According to [START_REF] Kaga | Caring and learning together: a crossnational study of integration of early childhood care and education within education[END_REF], there are conflicting arguments and ambivalent feelings about integrating ECEC services in education but relatively little information on its consequences. The lack of comparative research assessing this option motivated the launching of UNESCO's Caring and Learning Together project that investigates nine countries' experiences with different types of governance.

Integration within education as an expression of globalization

Far from being an expression of civil society movements integration within education is a government trend towards consolidating a national ECEC policy under the aegis of the ministry of education as part of the schooling system. This trend has evolved rapidly and in a worldwide scale and must be understood within the context of globalization. [START_REF] Dale | Globalisation and Education: Demonstrating a "Common World Education Culture" or Locating a "Globally Structured Agenda for Education[END_REF] explores very well the relationship between globalization and education in his approach summarized as the Globally Structured Agenda for Education (GSAE). The starting point, drawn on work in international political economy, is to see the changing nature of the world capitalist economy as the driving force of globalization and seek to establish its effects on educational systems. The label "Global" implies an extra-national focus, i.e., social and economic forces operating "supranationally and transnationally", "to elude, break down, or override national boundaries, while reconstructing the relations between nations". "Structured Agenda" means a "systematic set of unavoidable issues for nation-states that is framed by their relation to globalization" (Dale, 2000, p. 428). "Education" is concerned to the structures and process that "affect the life chances of individuals and groups and the overall mutual relations of educational systems to the wider social collectivities and institutions of which they are part" (idem, p. 439).

In this approach, globalization is seen as being constructed through three related sets of activities: economic, political, and cultural, which is characterized, respectively, as "hyper-liberalism, governance without government, and commodification and consumerism". Dale (2000, p. 436-437) explains that this form and extent of globalization is different from any other ever seen in the past, for two key factors. First, it makes possible for the first time to speak of a global economy that includes all nations of the world. It has resulted from the formal collapse of the only alternative to capitalism as well as the accelerating thrust of the commodification of everything, which accompanies it. Second, it is a triumph of a system, not a new hegemonic nation. As a result, of the multinational corporations and the technical changes in the velocity of financial exchanges, the global economy escapes the control of even the most powerful of nations. This also led to the creation of new forms of supranational governance that took on authoritarian forms previously unheard of. He also emphasizes that these changes result from changing conditions in the pursuit of profit, which remains the motor of the whole system.

In a critical fashion, every national regulatory policy is now molded and defined by both supranational forces as well as national political-economic forces. As a result of these indirect relationships, it is through the influence over States and regulation that globalization has its most obvious and important effects over national educational systems. Dale & Robertson (2002, p.11) point out that much of the literature has essentially treated globalization as a "process without a subject", which reveals a major source of the confusion and apprehension around globalization.

Transnational corporations, international financial institutions, and international organizations, such as the World Bank, the International Monetary Fund (IMF), OECD, the World Trade Organization (WTO), and G7/8 are some of the wide range of subjects and drivers of the globalization process and the possible meaning for the globalization of education.

With different degrees of influence and importance, these organizations have direct intervention in educational policies. This external influence was highlighted at the World Education for All (EFA) Conference held in Jomtien in 1990, since EFA served as a landmark for designing educational policies worldwide, especially in basic education [START_REF] Fullgraf | O UNICEF e a política de educação infantil no governo lula[END_REF].

However, beyond the focus limited to only education, this original broad vision of basic education i.e. basic learning skills for the world's population and the ambitious goal of a quality education for all has narrowed in many cases [START_REF] Torres | Educação para todos: a tarefa por fazer[END_REF]. Learning identified with school performance gave rise to standardized tests; 'the traditional confusion between education and teaching, as well as between teaching and learning, suggested that "improving education" is equivalent to "improving teaching" and that both "improve learning" and the emphasis on contents and results rather than processes, resulting in the adoption of assessment systems by most countries (TORRES, 2001, p. 44-45).The trend of the 90s that 'bet on increasing the time (of study, schooling, exposure to teaching) as a key variable to improve learning' illustrates the impact of that concept of learning (TORRES, 2001, p. 48). In this decade, most countries in Latin America, the Caribbean, Africa and Asia increased the number of years of compulsory education to eight, nine, ten, eleven or more. In many cases, this increase meant the inclusion of one or two years of pre-school education.

These changes in the broad concept of basic education directly influenced the identity and goals of early childhood education in the sense that 'the programmes are being promoted not so much as a function of child development, but as "preventive strategy of school failure" among the most "needy"' (TORRES, 2001, p. 35).

The first goal adopted by EFA, 'Expanding and improving comprehensive early childhood care and education, especially for the most vulnerable and disadvantaged children', involves a realignment of ECEC policies in developing countries. Two sets of priorities to achieve this goal were observed [START_REF] Haddad | An integrated approach to early childhood education and care[END_REF], which differ according to age group. One refers to the expansion of preschool classes for the age that precedes compulsory schooling, with a view to universalizing admission to ages 4-5, as a way of guaranteeing full access to formal schooling. The second refers to programmes for families and communities directed at children under 3.

Of note was the adoption of different terminologies by international organizations (such as Early Childhood Development -ECDused by WB, and now, also by UNICEF),which altered the concept of childhood as a social category and of early childhood education as the legitimate space for the child to live its childhood, undermining the concept of social responsibility and accentuating the gap between developed and developing countries.

The programmes that stem from ECD are also quite different; they include all the activities and interventions, which address the needs of young children and the contexts in which they are embedded, such as families and community environments, which does not always mean providing services directly to children in centre-based programmes2 .

In contrast to the EC Network on Childcare and OECD's Starting Strong programme, the literature of international organizations regarding developing countries advocates that 'programmes should be less costly and run by mothers or community leaders'; 'parents and close caregivers (such as older siblings) should be an equal target population'; 'settings should be community or home-based'; and 'private sector involvement should be encouraged' (ARANGO, 1998;YOUNG, 1996, cf HADDAD, 2002, p. 41).

Closely examining OECD's ECEC policy discourses and those of the WB, Mahon (2011) found similar trends. While the WB and its networks draw their inspiration from the residual American social policy model, targeting the poor while leaving the rest to rely on markets and families, Starting Strong reflects European social policy and especially the Nordic model, which embodies the principle of universality. There are also huge differences in the approach to women. The WB remains rooted in American family values and emphasizes women's maternal role, while the OECD and the EU remain committed to 'women's equality with men in the labour market and the importance of shared parental leave' (MAHON, 2011, p. 92).

Conclusion

In the globally structured agenda for education, there is little room for issues related to family life, gender equality and reconciliation between work and family responsibilities. As Mahon states (2011, p. 81), gender equity in the ECD discourse of the WB is less 'a matter of equality between men and women than as means for levelling the playing field between boys and girls with regard to access to education'. The implication for policy and practice is a conceptual reduction of early childhood education and care; in the education system, which is legitimized only as the first stage of basic education, and not as an integrated policy, that combines education and social dimensions.

The more recent changes in the organization of the Brazilian basic education testifies to it. In the year 2006, the compulsory schooling was extended from 8 to 9 years by the inclusion of all 6-year-old children in elementary education nationwide. As a result, the age range of ECEC decreased to 0 to 5. By 2013, the period of compulsory basic education was extended from the age of 4, even though the right to a place in preschool had been guaranteed since 1998 by the Constitution. Enrolment in preschool is no longer a family choice. There is a concern that the expansion of educational provision for pre-school will penalize access for children under 3, since the coverage for this age group is still low.

The strengthening of schooling for 4 to 5 year olds and the declining attention to collective education for children under 3; the resistance from the education system to the expansion of resources for full time provision, especially for the over 3's; the definition of a common national curriculum, pushing on the rights of learning; and the implementation of a national system of evaluation for all levels of education, are some symptoms of a global agenda for education. An agenda that reduces the broader meaning of education to learning and weakens ECEC as an integrated system, since it eliminates the fundamental social dimensions that has supported this concept.

For a critical discuss on the view on the World Bank's view of early childhood and ECD programmes, see[START_REF] Mahon | Transnationalizing (child) care policy: the OECD and the World Bank[END_REF]), Penn (2002) and[START_REF] Rosemberg | Multilateral organizations and early child care and education policies for developing countries[END_REF] among others.


L Birbrair

A Fernandes

J E Sampaio

LIPSCHITZ REGULAR COMPLEX ALGEBRAIC SETS ARE SMOOTH

Keywords:

A classical Theorem of Mumford implies that a topologically regular complex algebraic surface in C 3 with an isolated singular point is smooth. We prove that any Lipschitz regular complex algebraic set is smooth. No restriction on the dimension and no restriction on the singularity to be isolated is needed.

Introduction

A classical theorem proved by David Mumford in 1961 [START_REF] Mumford | The topology of normal singularities of an algebraic surface and a criterion for simplicity[END_REF] is stated as follows: a normal complex algebraic surface with a simply connected link at a point x is smooth in x. This was a pioneer work in the topology of singular algebraic surfaces. An important sequence of works in this area and some applications to the 3-folds topology were deeply stimulated by this theorem.

From a modern viewpoint this result can be seen as follows: a topologically regular normal complex algebraic surface is smooth. Since, in C 3 , a surface is normal if and only if it has isolated singularities, the result can be formulated as follows: topologically regular complex surface in C 3 with isolated singularity is smooth. The condition on the singularity to be isolated is important because there are examples of non-smooth and topologically regular surfaces, with non-isolated singularities.

There are also examples of non smooth surfaces in C 4 (see Section 5 of [START_REF] Tibar | Beyond Mumford's theorem on normal surfaces[END_REF]) with topologically regular isolated singularity .

Here we study Lipschitz regular complex algebraic sets. Lipschitz regularity simply means that the complex algebraic set is a Lipschitz submanifold of C n . The main result is that Lipschitz regular points of a complex algebraic set are smooth points, i.e. the conclusion of the Mumford theorem holds without any restrictions.

There are two basic ingredients in the proof. The first one is the theory of normal embedding, created by Birbrair and Mostowski [START_REF] Birbrair | Normal embeddings of semialgebraic sets[END_REF] (The paper contains some lines describing the theory). Using the Bernig-Lytchak [START_REF] Bernig | Lytchak Tangent spaces and Gromov-Hausdorff limits of subanalytic spaces[END_REF] map (see also [START_REF] Birbrair | Normal embedding of complex algebraic surfaces, in Real and Complex Singularities[END_REF]), one can make a reduction of a Lipschitz regular point to its tangent cone. The second ingredient is the extraordinary theorem by David Prill [START_REF] Prill | Cones in complex affine space are topologically singular[END_REF]. D. Prill proved that algebraic and topologically regular complex cones are smooth.

Acknowledgements. We would like to thank Andrei Gabrielov, Walter D. Neumann and Donu Arapura for their interest on this work.

Normally embedded sets

Given a closed and connected subanalytic subset X ⊂ R m the inner metric on X is defined as follows: given two points x 1 , x 2 ∈ X, d X (x 1 , x 2 ) is the infimum of the lengths of rectifiable paths on X connecting x 1 to x 2 . According to the real cusp x 2 = y 3 , one can see that the inner metric is not necessarily bi-Lipschitz equivalent to the Euclidean metric on X. A subanalytic set is called normally embedded if these two metrics (inner and Euclidean) are bi-Lipschitz equivalent.

Proposition 2.1. Let X ⊂ C n be an algebraic subset. Let x 0 ∈ X be such that the reduced tangent cone

T x 0 X := |C x 0 X| is a linear subspace of C n . If there exists a neighborhood U of x o in X such that U is normally embedded, then x 0 is a smooth point of X.
Proof. Since T x 0 X is a linear subspace of C n , we can consider the orthogonal projection

P : C n → T x 0 X.
We may suppose that x 0 = 0 and P (x 0 ) = 0.

Notice that the germ of the restriction of the orthogonal projection P to X has the following properties:

(1) It is finite complex analytic germ of map;

(2) If γ : [0, ε) → X is a real analytic arc, such that γ(0) = 0, then the arcs γ and P • γ are tangent at 0.

Then the germ at 0 of P |X : X → T 0 X is a ramified cover and the ramification locus is the germ of a codimension 1 complex analytic subset Σ of the plane T 0 X.

The multiplicity of X at 0 can be interpreted as the degree d of this germ of ramified covering map, i.e. there are open neighborhoods U 1 of 0 in X and U 2 of 0 in T 0 X, such that d is the degree of the topological covering:

P |X : X ∩ U 1 \ P -1 |X (Σ) → T 0 X ∩ U 2 \ Σ.
Let us suppose that the degree d is bigger than 1. Since Σ is a codimension 1 complex analytic subset of the space T 0 X, there exists a unit tangent vector v

0 ∈ T 0 X \ C 0 Σ.
where C 0 Σ is the tangent cone of Σ at 0. Since v 0 is not tangent to Σ at 0, there exists a positive real number k such that the real cone

{v ∈ T 0 X | |v -tv 0 | < tk ∀ 0 < t < 1}
does not intersect the set Σ. Since we have assumed that the degree d ≥ 2, we have two (different) liftings γ 1 (t) and γ 2 (t) of the half-line r(t) = tv 0 , i.e. P (γ 1 (t)) = P (γ 2 (t)) = tv 0 and they satisfy γ i (t) -0 = t, i = 1, 2. Since P is the orthogonal projection on the reduced tangent cone T 0 X, the vector v 0 is the unit tangent vector to the images P • γ 1 and P • γ 2 of the arcs γ 1 and γ 2 at 0. By construction, we have dist(γ i (t), P -1 |X (Σ)) ≥ kt (i = 1, 2).

On the other hand, any path in X connecting γ 1 (t) to γ 2 (t) is the lifting of a loop, based at the point tv 0 , which is not contractile in the germ, at 0, of T 0 X \ Σ. Thus such a path must be longer than kt. It implies that the inner distance, d inner (γ 1 (t), γ 2 (t)), in X, between γ 1 (t) and γ 2 (t), is at least kt. But, since γ 1 (t) and γ 2 (t) are tangent at 0, that is |γ 1 (t)γ 2 (t)| t → 0 as t → 0 + , and k > 0, we get a contradiction to the fact that X is normally embedded near 0.

Main result

All the sets considered in the paper are supposed to be equipped with the Euclidean metric. When we consider the inner metric, then we will emphasize it clearly.

Definition 3.1. A subanalytic subset X ⊂ R n is called Lipschitz regular at x 0 ∈ X if there is an open neighborhood U of x 0 in X which is subanalytically bi-Lipschitz homeomorphic
to an Euclidean ball.

Theorem 3.2. Let X ⊂ C n be a complex algebraic variety. If X is Lipschitz regular at

x 0 ∈ X, then x 0 is a smooth point of X.
Proof. Let X ⊂ C n be a complex algebraic variety. We start the proof from the following lemma:

Lemma 3.3. If X is Lipschitz regular at x 0 ∈ X, then there exists a neighborhood U of x 0 in X which is normally embedded in C n .

Proof of the Lemma. Let X be Lipschitz regular at x 0 . By definition, there exists a neighborhood U of x 0 in X and a subanalytic bi-Lipschitz homeomorphism ψ : B → U, where B is an Euclidean ball. Since ψ induces a bi-Lipschitz homeomorphism between the metric spaces (B, d B ) (B equipped with its inner metric) and (U, d U ) (U equipped with its inner metric) (see [START_REF] Birbrair | Normal embeddings of semialgebraic sets[END_REF]), we have positive real constants λ 1 and λ 2 such that

λ 1 |p -q| ≤ |ψ(p) -ψ(q)| ≤ λ 2 |p -q| ∀p, q ∈ B and λ 1 d B (p, q) ≤ d U (ψ(p), ψ(q)) ≤ λ 2 d B (p, q) ∀p, q ∈ B.
On the other hand, Euclidean balls are normally embedded; or more precisely, d B (p, q) = |p -q| for all p, q ∈ B. By inequalities above, we have that

d U (ψ(p), ψ(q)) ≤ λ 2 λ 1 |ψ(p) -ψ(q)| ∀ p, q ∈ B.
In other words, U is normally embedded.

An algebraic subset of C n is called a complex cone if it is a union of one-dimensional linear subspaces of C n . The next result was proved by David Prill in [START_REF] Prill | Cones in complex affine space are topologically singular[END_REF].

Lemma 3.4 (Theorem of Prill [START_REF] Prill | Cones in complex affine space are topologically singular[END_REF]). Let V ⊂ C n be a complex cone. If 0 ∈ V has a neighborhood homeomorphic to a Euclidean ball, then V is a linear subspace of C n Let us suppose that X is Lipschitz regular at x 0 . Let C x 0 X be the tangent cone of X at x 0 . Let h : U → B be a subanalytic bi-Lipschitz homeomorphism where U is a neighborhood of x 0 in X and B ⊂ R N is an Euclidean ball centered at origin 0 ∈ R N .

Let us suppose that h(x 0 ) = 0. Then the derivative of h, dh : |C x 0 X| → T 0 B, defined by Bernig and Lytchak [START_REF] Bernig | Lytchak Tangent spaces and Gromov-Hausdorff limits of subanalytic spaces[END_REF] (see also [START_REF] Birbrair | Normal embedding of complex algebraic surfaces, in Real and Complex Singularities[END_REF]), is a bi-Lipschitz homeomorphism between the reduced tangent cones |C x 0 X| and T 0 B = R N . In particular, it proves that |C x 0 X| is also bi-Lipschitz regular at x 0 . By the Theorem of Prill (Lemma 3.4) , we have that the reduced cone |C x 0 X| is a linear subspace of C n . In order to finish the proof we just need to recall Lemma 3.3 and Proposition 2.1.


Response

Summary of this RFI

This RFI requests information on what capabilities (functionalities, methodology definition and process guidance) of MDA tools the MDA user community currently use for their projects, and which capabilities they would like to have. Responses should distinguish between capabilities they use now and capabilities they would like to have. Since different projects and applications have different needs, we also request how and why the capabilities are and/or would be useful. Responders are asked to distinguish between capabilities that are required (their company or project will not purchase a tool without it) and those that are preferred in an MDA tool.

Information obtained may be used to develop standards for compliance levels for MDA tools, or to identify new standards that are required by the MDA user community. This RFI also gives MDA users a method to communicate their needs to other users and to the MDA tool vendor community. The information will help tool suppliers decide which features to keep, which features to add, which features to enhance, and which features to drop.

Detail

Within this section, we provide the core of our response, i.e. our set of answers to the different RFI questions according to our MDE global approach and to the corresponding implemented AMMA Platform. Note that we sometimes use within our answers a specific terminology which is explained in the glossary (see section 3.0).

Models

1. What kinds of models do you use to apply MDA processes? 2. What kinds of models do you use to model your system/software for MDA?

In our MDA general processes, we use the three different types of models which are terminal models (M1-level), metamodels (M2-level) and metametamodels (M3-level): these kinds of models correspond to the three main levels promoted by the OMG in its proposed MDA vision. For example, we may have a UML 1.4 for (terminal) model of the OMG organization (task forces, interest groups, staff, members, etc). We may also consider the UML 2.1 metamodel or the MOF 1.4 metamodel. Note that according to the latest versions of the MDA guide, all these three artifacts may be considered as (abstract) models. This means that they share common properties and behaviors. For example, all these artifacts may be stored, retrieved, transformed, etc.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 4

More generally, each model (whatever its type) conforms to its reference model: a terminal model conforms to a metamodel, a metamodel conforms to the metametamodel and the metametamodel conforms to itself (and is unique within a particular technical space, see the glossary of section 3.0). The terminal models are the direct representations of real-world systems.

We summarize this overall vision in the following conceptual schema: On the left of the dotted line, Figure 1 shows the modeling world which is of main interest to us here. On the right of this dotted line, there is the real world.

We make a strong difference between a system (drawn as an oval) and a model (drawn as a rectangle). For example, we could consider the real OMG organization as a system S and separately an UML model M of this organization: we then say that M is a representation of S (in short repOf).

Any MDA approach is based on a precise and unique metametamodel (M3). Unfortunately, there are several possible choices like MOF 1.4, MOF 2.0, Ecore, etc. This is the reason why we have defined a minimal M3 pivot named KM3 (Kernel MetaMetaModel). The KM3 pivot comes with operational mappings to most common proposals. These mappings are implemented in ATL (ATLAS Transformation Language), which is dedicated to model-to-model transformation, and are available as open-source components.

Platform independence is one of the key initial ideas of MDA. If we cannot achieve this, a solution is not MDA compliant. Independence from the M3 has been found of paramount importance in AMMA. Initially, the ATL virtual machine was built on top of Netbeans/MDR (based on MOF 1.4). Then, we had to rapidly cope with Eclipse/EMF (Eclipse Modeling Framework, based on Ecore). Through this experience, we learned the value of being M3-independent.

In the future, AMMA may use new versions of the MOF or other different platforms like the Microsoft DSL Tools. This is possible thanks to the KM3 pivot that makes AMMA truly platform independent and thus MDA-compliant. KM3 is a textual DSL allowing easily defining a metamodel. This metamodel may immediately be transformed in another notation like Ecore. Of course, there are plenty of other ways to generate a metamodel like using a UML CASE tool to draw a class diagram and transforming the resulting XMI into a XMI for a metamodel (this last operation is called promotion because it takes as input an M1-entity and produces as output an M2-entity). Metamodels are the central artifacts in any MDA activity. There are different sources for such metamodels. The primary one is of course the set of standardized OMG MOF metamodels (UML, SPEM, KDM, etc). Another source of metamodels may be the open-source communities like Eclipse that is providing Ecore metamodels. But we have found in practicing MDA with AMMA that there is also an important need for locally defined metamodels. For example, in a chain of M2M transformations, there may be a need for ten specific metamodels. Sometimes these metamodels may be shared: this brings new important issues about how to organize libraries of metamodels. There is also an issue about metamodel reusability, which brings to attention the need to have a precisely defined mechanism for metamodel extension.

A metamodel represents the abstract syntax of a DSL. Since there are a lot of such DSLs, there will be a lot of metamodels too (see the answer to question 3).

In addition of a metamodel, a DSL may be associated to some concrete syntaxes and some semantics as well. Projects like Eclipse GMF (Graphical Modeling Framework) or Microsoft DSL Tools allow weaving a graphical concrete syntax to the metamodels related to a DSL. The same models may be expressed in different formats. Since the AMMA platform is currently built upon Eclipse, we often use the XMI 2.0 variant of EMF to serialize our models. However, we also provide several bridges, implemented by ATL transformations, between the Eclipse Modeling Framework, and other modeling environments or formats (see the different libraries or "zoos" of metamodels).

Which modeling languages should an MDA tool support, and why?

According to the nature of the MDA process to perform, and also to the kinds of systems to model, we design different domain-specific metamodels (by using the KM3 language). These metamodels define the abstract syntaxes of Domain-Specific Languages (DSLs), and are tuned to domain-specific purposes. The systems to model (it can be software but not necessarily) are represented by terminal models that conform to these domain-specific metamodels.

Our MDA approach is thus metamodel-independent (i.e., not based on a limited set of modeling languages). We believe that domain-specific languages are more useful to capture relevant information in models than one or a few generalpurpose languages are. As a consequence, we recommend that MDA tools should be able to support the definition of DSLs for different purposes, and should not be limited to a few languages only. This is a significant difference with the approach offered by most CASE tools, which are based on a single general-purpose metamodel: UML.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 6

For example, within the AMMA platform, it is possible to define different modeling languages for domain-specific purposes. To this intent, we specify their abstract syntaxes as different metamodels (by using KM3). When their concrete syntax is textual, we define it by using TCS (see the glossary of section 3.0). Thus, the users (e.g., domain experts) can define and use different DSLs depending on the kind of systems they want to model and also on the point of view from which they want to observe them.

4. How important is it for you to see both graphical and textual views of your models as you build them?

As it is mentioned in the question, we are considering different views (graphical and/or textual) on the same models. By experimenting with our AMMA platform, we noticed that having a textual representation of models is most of the times sufficient. For instance, the KM3 language (which is a textual one) seems to be really adapted for defining metamodels even though it does not directly provide a graphical view of the produced metamodels. By using this kind of DSLs, we do not feel the particular need for always having graphical views. This type of view may be user-friendly but often becomes difficult to handle when dealing with large models (several hundreds entities). However, combining both views (textual and graphical) may be a useful additional feature when building models (i.e., metamodels and/or terminal models).

Once again, we believe that a model development toolkit should allow easy definition of DSLs: 1) By creation and modification of abstract syntaxes represented by metamodels. 2) By definition of textual concrete syntaxes. 3) By definition of graphical/visual concrete syntaxes. 4) By definition of semantics. Our proposal for 1) is KM3 but many other solutions are also possible in AMMA (e.g., MOF, Ecore). Our proposal for 2) is TCS for mapping metamodels and grammars. We do not offer a specific solution for 3) because we are using the Eclipse GMF (Graphical Modeling Framework) project. Our proposal for 4) is ATL that may be used to map unknown to known domains. For instance, a Workflow DSL can be mapped to a Petri net (i.e., a well-known and precisely defined domain) metamodel by an ATL transformation.

What system architectural viewpoints do you/would you like to model:

Enterprise, Information, Computation, Engineering, Distribution, Other?

According to our vision of MDA, any viewpoint on any system may potentially be modeled by creating or extending the appropriate DSLs. Our approach does not have any restriction concerning the different system architectural viewpoints that may be modeled. We believe that, for a given problem, every relevant Within our approach, we want to consider the problem of viewpoints on systems in the broad sense. The different possible architectural visions of a system are only a specific subset of the overall problem. Again here, any viewpoint on a system or on a model may be defined by an adequate DSL. With our platform, we plan to experiment on this general topic, define the main related concepts and provide some corresponding tooling.

6. Which elements of UML and its extensions (e.g., SysML) do you need an MDA tool to support?

We need the MDA to address most parts of UML, SysML but also many other metamodels. MDA is not restricted to UML and SysML and can be potentially applied independently of them.

We currently consider that one of the most important risks and challenges of the OMG MDA is the lack of modularity in the expression of most standard metamodels. UML profiles are not a scalable solution to these problems. Most users want to use only well-defined parts of UML, SysML, SPEM, KDM, etc, and it is currently very difficult to delimit precise boundaries within metamodels such as UML and SysML. There is a growing demand for much simpler and clearer modularity features that will allow user delimiting precise scope and tailoring the metamodels to the exact needs of a company or organization.

What capabilities should an MDA tool have for describing actions?

8. How should actions for states, transitions, and operations be modeled? For example, should actions be described by activity diagrams, sequence diagrams, action language, and/or code? 9. When the actions are described with action language or code, how should they be integrated with the model?

After experimenting in a previous project with executable models and metamodels, we do not believe anymore in this solution.

We have been using Smalltalk blocks (similar to Lisp closures) attached to model and metamodel elements. In the initial period, this seemed interesting since these "semantic actions" written as Smalltalk blocks were using a precise API to access model and metamodels elements. But after some experiments, this approach does not seem to scale up. There will be difficulties in converging on a standard action annotation language while Eclipse is already using Java and MS DSL Tools are using C#.

Our position is to avoid polluting the metamodels and models with such information. Instead, we propose a clear separation of concern based on the notion of model weaving (like in the AMW or ATLAS Model Weaver, see next answer): the actions should be kept separated in a decoration model. This decoration model may conform to any appropriate action metamodel, depending on the problem at hand. This metamodel may define activity diagrams, sequence diagrams, action language, code, or more precise formalisms like Petri net.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 8

In other words, we do not believe it is possible to standardize one unique action language. There have been a lot of experiments in this field and there are currently a lot of proposals. Again, our position here may be summarized as: "do not pollute your metamodels". Instead, as we have shown in the AMW Eclipse component (see the AMW use cases), it is possible to separately decorate metamodels with a number of different action languages (or even programming languages) by the well-established technique of model weaving.

What restrictions should an MDA tool impose on actions?

As we previously mentioned it, our approach is metamodel-driven and based on the concept of DSL. By following these principles (and in order to be able to describe actions), an MDA tool can provide several DSLs for expressing actions. These DSLs could be generic with extension capabilities, so that it is possible to define new actions DSL (for specific actions-related purposes) as extensions of the generic DSLs. Actions should be represented (i.e., described) by models that conform to "actions" metamodels. As a consequence, the kinds of actions that may be expressed are not restricted: their possible formats or potential options should be determined by the corresponding "actions" metamodels. For instance, the UML metamodel provides some ways to describe actions but we may define a lot of other ones.

The produced "action" models may be woven with other models, by using the ATLAS Model Weaver (AMW) solution for example. The behaviors described by the actions may be applied to the corresponding modeling elements, and thus produce other models, etc.

What types of marks on the model do you want supported by the tools?

Model marking is a very important issue. The previous answers on how to describe actions by annotating model elements will be repeated here in a more general context. The problem may be abstractly defined as follows: a) We have an original model M a and we want to decorate this model with some data in order to get a decorated model M g . b) The question of which metamodels M a and M g do conform to is left unanswered at this time. c) The decoration information should ideally constitute a model by itself if possible. d) Decorations should not destroy nor pollute the original model. e) It should be possible to apply multiple independent decorations to a same model. f) It should be possible to decorate an already decorated model. g) It should be possible to transform a decoration model into another model (M2M transformation). We believe that MDA processes explicitly or implicitly assume the existence of facilities for marking or decorating models. The MDA guide is full of references 12. How should the marks on the model be expressed?

MDA tools should be able to support any kind of marks. But within our MDA approach, we generally prefer to talk about "marking models" instead of "marks". Following the same principles as those previously presented for expressing the actions, we represent marks on models by other models that conform to specific marks metamodels. Because in this case a given element of a system may be referenced in several different models, we recommend using a weaving mechanism in order to establish some correspondence links between these models. Once again, the goal is to not pollute the models with a lot of additional data (instructions, marks, etc). As a much more modular alternative, we suggest using model weaving as implemented by AMW.

Data

What work products should an MDA tool produce?

Since in a MDA approach models are considered as first-class entities, the main artifacts produced should be models (i.e., terminal models and/or metamodels). These models may then be used to perform MDE operations (mainly derived from transformations and/or weavings) and for producing different visualizations or outputs based on their content (in graphical formats, textual formats or both of them). Typically, the management of all these models and their metadata is one of the goal of our global model management (or GMM, see the glossary of section 3.0) approach, which is based on the core concept of megamodel.

The following conceptual schema (derived from Figure 1) summarizes our overall GMM approach:

Figure 2: GMM Conceptual Framework

A megamodel is a terminal model in which elements are representing models, relationships between them and more generally metadata on them. By extension of this concept, we define the concepts of "zoo" and "mirror zoo" that correspond to megamodels in which all elements (i.e., all models) conform to a single metamodel. For instance, in a zoo of metamodels, all elements conform to a single metametamodel (e.g., MOF).

14. What are the inputs (documents, tables, data) to your MDA process and MDA tools? 15. Which data formats should be supported for input/output data?

The inputs/outputs of an MDA process or tool are strongly linked to the type of system you want to model and to the viewpoint from which you want to observe it. Indeed, the formats of the inputs/outputs may differ depending on the systems which are considered. We strongly believe in the notion of "projection" between different technical spaces, and especially from/to the "modeling" technical space. It consists in switching from the heterogeneous world of the systems to the homogeneous world of the models (injection) and vice-versa (extraction). According to this vision, the more projectors a MDA process or tool provides and/or supports the more efficient and valuable it is.

At what level should model elements and MDA artifacts be version controlled?

Because in a MDA approach most of the artifacts (if not all) are models, we believe that we should focus on the control of the different versions of a model.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 11

The main problem is about how to deal with different versions of a same model without loosing any information. Once again, this is one of the main goals reached by our global model management (GMM) approach and the metadata it handles (see the answer to question 13).

One possible solution for implementing this version control is to use AMW: the differences between two different versions of a model may themselves be represented as a model (a weaving model). The weaving model conforms to an extension of a core weaving metamodel. The core weaving metamodel defines basic link management semantics. It is extended with different kinds of links depending on the application scenario. In the case of version control, "difference" links can be defined to capture differences between models. The weaving model should explicitly define the relationships between the model elements. A complete use case implementing such an approach and using AMW is available here.

Interoperability

17. What interchange capabilities do you require from MDA tools? For example, XMI interchange, diagram interchange.

Interoperability between different MDA tools and produced artifacts is for us a main issue in the MDA global approach. Indeed, one of the most important properties of models is their portability between several platforms and/or environments. As a consequence, an MDA tool really needs model import/export facilities. According to our different experiments with the AMMA Platform, XMI seems to be at the current time the best and most commonly used format for exchanging models. For instance within the Eclipse platform, the EMF XMIbased format is widely used and reliable.

18. Between which types of MDA tools do you need interoperability? Please refer to the types of tools in the taxonomy, if possible.

The main idea of MDA (and MDE in general) is to gather the problems in the homogeneous world of the models so that it breaks the complexity which can exist in the heterogeneous worlds of the systems. As a consequence, there should not be any restriction in the possible exchanges of models between different types of MDA tool. All the MDA tools should be interoperable because all the exchanged artifacts should be models expressed in well-known formats. In our opinion, MDA tools should support all of the OMG standards. In addition to the already existing ones, we provide below a set of possible MDA standards that may be interesting to develop:

-Workflowing operations on models -Global Model Management -Model weaving or composition -Mappings (or projections) to external spaces (XML, EBNF, etc)

Transformations

21. Which transformations do you require? For example, Model  Code, Model  Documentation. Please describe the types of transformations such as inputs, outputs, and markings as specifically as possibly.

We consider two main families of transformations: model-to-model and modelto-text (or text-to-model).

Within the AMMA Platform, we already provide an important library of modelto-model (M2M) transformations, expressed in ATL, covering a large set of possible domains of application.

The model-to-text and text-to-model transformations respectively correspond to possible implementations of the concepts of "extractors" and "injectors" (both are "projectors", as already explained in the answer to question 14 and 15). To this intent, the AMMA Platform provides a tool named TCS that allows defining and building such "projectors".

Which transformations should be reversible?

There are no general rules for specifying the kinds of transformations that should be reversible. It depends on the kind of MDA process the transformation is designed for. We believe that there is no need for a real reversibility mechanism in a transformation language. While developing a transformation (and only if necessary), the corresponding reverse transformation may be also manually implemented and/or (at least partially) generated. We have followed this principle within the AMMA Platform for the development of ATL. However, the reversibility of model transformations can be supported by defining relationships between elements at a higher abstraction level, by the means of weaving models. The weaving models define declarative links that are used as specification for producing transformations. The kinds of links are defined as extensions to a core weaving metamodel (see the answer to question 16). We already experimented within the AMMA the generation of ATL transformations (by using what we name High Order Transformations or HOT, see the answer to questions 24-25) in order to transform UML Profiles into DSLs, and vice-versa. As main result, we were capable to create a single weaving model that was used to generate ATL transformations in both directions. This weaving model is the only user-created artifact, and may be considered as a bidirectional transformation.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 13

Which transformations should be traceable?

We provide here the same kind of answer as for the previous question about reversibility: the need for traceability depends on which kind of model you want to transform and/or produce. However, it may be useful to have a traceability mechanism provided with the language (but not necessarily directly integrated into the language). As a consequence, we are currently experimenting within the AMMA Platform in order to provide a simple traceability mechanism based on a traceability metamodel.

Actually, the traceability metamodel is a weaving metamodel, because it keeps links between several models (source and target). This weaving metamodel consists in a traceability extension to the core weaving metamodel. The traceability extension is available in the AMW metamodel Zoo. In our experiments, we used higher-order transformations (HOT, see the answer to questions 24-25) that take ATL transformations as input and that produce another ATL transformation as output. This output transformation creates an additional weaving model to store the traceability information.

Between which pairs of viewpoints do you/would you like to use automated transformations? 25. Do you need to customize or build your own transformations?

We believe that an MDA tool should permit both: a user may want to build its own transformations from scratch or may also want to customize some already provided basic transformations. Another solution, which is a very promising approach, is to use what we name High Order Transformations or HOT. A higher-order transformation is a transformation T HOT : T IN  T OUT , such that the input and/or the output models are transformation models. Higher-order transformations either take a transformation model as input, either produce a transformation model as output, or both. We learned that there are many possible uses for HOTs by conducting several experiments that use them:

 A HOT can be used to modify existing transformations, such that the resulting transformation produces traceability information (see the answer to question 23).  We made several experiments with HOTs that take weaving models as input and that produce ATL transformations as output. For instance, one weaving model with bidirectional links was used to produce two ATL transformations (see the answer to question 22).  We have developed extensions of weaving metamodels that are used as high-level specifications for interoperability operations. The higherorder transformations take these weaving models as input and produce executable transformations in ATL (the AMW use cases provides several examples that use this approach).

OMG Request for Information (RFI) MDA Tool Capabilities RFI 14

What kinds of characteristics should transformations support? For example, configuration management of transformations? Deployment, composition, graphical interface, command line interface?

In real MDA processes, we consider complex chains of transformations more than simple elementary transformations. As a consequence, one of the main characteristics of the transformations is that they can be composed. Thus, transformation tools builders should provide facilities for chaining transformations.

Within the AMMA Platform, we have implemented ATL-specific ANT tasks to this intent. They allow building ANT scripts for automating the execution of complex chains of ATL transformations involving several models (i.e., terminal models and metamodels). However, we believe that transformation chaining should be provided by a workflow DSL, and that such a language should be standardized by the OMG (see answer to question 20).

Process

How is MDA used in your development process?

Because our activity is focused on MDA and on its different applications, we try to use MDA principles as much as possible in our development processes but also in all our processes in general. We concentrate most of our efforts in the development of new MDA tools and technologies so that MDA is always our main interest.

We apply this principle within the AMMA Platform: most of the tools we provide are based and/or use ATL, which is our transformation language, and its corresponding virtual machine and engine. Due to this architecture, AMMA fully meets the goals of platform independence as stated in the original MDA guidelines. Moreover, because the DSLs offered by AMMA (e.g., ATL, KM3, TCS, AMW core) provide means to define new DSLs, they can also be used to define themselves. We follow this principle because we believe that MDA should also be used to develop MDA tools. For instance, the abstract syntax of KM3 is specified in KM3, its concrete syntax in TCS, and its semantics is represented by ATL mappings to MOF 1.4, Ecore, etc.

What types of tools do you need an MDA tool to integrate with? Please refer to the types of tools in the taxonomy, if possible.

An MDA tool should first interface with any other MDA tool and also with non-MDA tools. Let us consider these two categories separately.

A) Interface with another MDA tool.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 15

According to Wikipedia, an MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels. In the following section "model" is interpreted as meaning any kind of terminal model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. For example an analyst may create a UML initial model from its observation of some loose business situation while a Java model may be automatically derived from this UML model by a Model transformation operation. An MDA tool may be one or more of the following types:

-Creation Tool: A tool used to elicit initial models and/or edit derived models. Some of these tools may be used in collaborative environments (e.g. Jazz-based) -Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model. Note that all these kinds of operations may be implemented by using model-to-model transformations, for instance in ATL. -Transformation Tool: A tool used to transform models into other models or into code and documentation. The ATLAS Transformation Language (ATL) is such a tool. -Storage and retrieval tool: a tool that allow to store models and to retrieve them from some repository. The Teneo Eclipse project is such a tool. Another example is the Adaptive repository. -Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel, but not always. The ATLAS Model Weaver (AMW) can be used in this scope. -Matching Tool: A matching tool is used to find links between elements of different models. The links can be used in many application scenarios, for instance as the input for a Compare and Diff Tool, or to easy the task of producing transformations. The ATLAS Model Weaver (AMW) provides generic matching mechanisms. -Compare and Diff Tool: A tool able to take for example two models as input and to create a model representing their difference. This difference is a model and could later be used by a composition tool. Note that all these models may not conform to the same metamodel.

The ATLAS Model Weaver (AMW) can also be used in this scope. -Test Tool: A tool used to "test" models. Testing a model means verifying that the model has some particular properties. Should not be confused with a model of the test related to some code generated from another model. -Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution. It may work if a model is somewhat decorated or annotated with actions written in a given language like Java or C# or any proprietary or standard language.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 16

-Metadata Management Tool (Global Model Management Tool): A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.). The Eclipse/GMT AM3 (ATLAS MegaModel Management) component goal is to intent to address this Global Model Management problem. -Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models. Some tools perform more than one of the functions listed above. For example, some creation tools may also have transformation and test capabilities. There are other tools that are solely for creation, solely for graphical presentation, solely for transformation, etc. The Eclipse/GMT MoDisco (Model Discovery) component goal is to intent to provide such a reverse-engineering framework. One of the characteristics of MDA tools is that they mainly take models (e.g. MOF models or metamodels) as input and generate models as output. In some cases however the parameters may be taken outside the MDA space like in model to text or text to model transformation tools. The Eclipse top level modeling project (EMP) is currently developing a set of open source tools of various profiles (EMF, GMF, M2M, GMT, etc.). So any two MDA tools should integrate in a smooth way without any problem. The only aspect that needs being taken care of is the global model management (GMM). Several GMM facilities should take care of any modeling artifacts created, deleted, updated or simply available to a given tool. A given MDA tool should bear a signature stating which kinds of models it is supposed to use and which kinds of models it is supposed to produce. B) Interface with a non-MDA tool. A non MDA tool does not use models or modeling standards like XMI. As a consequence its collaboration with MDA-tools should be handled via projectors (i.e., injectors and/or extractors). These projectors are transformations between an external space and the MDA space. Some may be generic (i.e., metamodel-independent), whereas others may be specific (i.e., metamodel dependent). There should be libraries of such projectors for the main tools and the main technical spaces. As an example, it should be possible to define a chain of MDA transformations with, inside this chain, some other operation performed by an external tool.

What test capabilities do you need an MDA tool to provide?

An MDA tool should be enhanced with model measurement tooling in general (and not only test capabilities: see the answer to question 36). However, concerning more particularly test capabilities, it should be interesting to have a tool for making some constraints validation on metamodels (such as checking if each abstract class of a metamodel has at least one subclass, etc). Constraint-based model construction would also be a useful facility.

When in the lifecycle do you wish to simulate and/or execute a model?

We already have implemented a model execution engine dedicated to the execution of model-to-model transformations (named the ATL virtual machine): it allows performing ATL transformations, which are models that conform to the ATL metamodel. This is the main kind of executable models we consider within our MDA approach. Because transformations may be involved in each step of the lifecycle, there is no particular moments for "executing" transformation models. However, an MDA tool should keep track of model versions in a GMM, so that it can either automatically re-execute transformations when the source models have changed or suggest that they should be re-executed. Note that many models are not directly executable but may be transformed into executable ones. This is a widely used technique within the AMMA platform.

Miscellaneous

Aside from customization of transformations (see question 25), what kinds of user customizations and user preferences should an MDA tool support?

According to our vision of MDE, the main customizations that an MDA tool should support concern the Domain-Specific Languages (or DSLs). Indeed, it should permit to create, design, add and manage new DSLs into the environment by using the providing DSL-specific facilities. In an ideal situation, the domains of application of the added DSLs should not be restricted by the provided facilities.

Another more advanced but very useful user customization should be to allow the connection of external tools directly into the environment by connecting to some provided "generic" interfaces. Thus, a user may customize its own modeling environment by adding some specific tools that fix its requirements and needs.

32. What capabilities do you require for MDA tools to support non-functional requirements in specialized systems? For example, embedded systems, real-time systems, fault-tolerance, high availability, etc. 33. What capabilities do you require for matching a PIM to an existing architecture?

In order to do that, we absolutely need two distinct items:

-A model of the platform (i.e. a Platform Description Model or PDM).

-A facility to weave the PIM to the PDM in order to later generate a PSM. Weaving PIM and PDM may be achieved with the help of a tool like AMW. The KM3 language and the corresponding Eclipse textual graphical editor (TGE) can be considered as a modeling tool dedicated to the design of metamodels.

Although we do not provide a specific analysis "tool", a library of ATL transformations producing metrics (which are represented as models) on models is currently being developed. It will be used, in the future, as the analysis tool of the AMMA Platform.

The ATL component, including an Eclipse IDE with a specific view, editor, outline and debugger, is the AMMA transformation tool.

The AMW component, also including a complete Eclipse IDE, is designed for model weaving and in this way can be considered as a composition tool. The AM3 component is our metadata management tool (Global Model Management or GMM tool in the context of the AMMA Platform). In our future vision of our platform, it would be the core component of the environment because it allows globally managing and providing modeling resources (such as metamodels, transformations, etc). Version control facilities should also be provided by this component. The TCS component allows building "projectors" so that it can be considered as a transformation tool. Since injectors (which are projectors) allow creating models from already existing data in different grammar-based formats, TCS can also be considered as a reverse-engineering tool. Concerning reverse-engineering, there is no single dedicated component directly integrated into the AMMA Platform. However, the MoDisco component (which has been recently created and is currently being developed in parallel with the AMMA Platform) will provide a set of tools for performing model-driven reverse-engineering.

35. Do we need these to be in a suite of tools vs. one tool. Perhaps tooling environment.

We do not believe in the idea of having one single tool for performing all the possible MDA operations and following all the step of a MDA process.

Our approach is based on the fact of considering a simple general environment (for the time being, we use Eclipse) in which we can connect the set of the tools required for our MDA processes. The tools which are integrated into this environment may come from tool suites (but not necessarily, it may also be single tools) and may be provided by different vendors or tool builders.

What kinds of analysis do you need an MDA tool to support?

Because in our approach of MDA most of the handled artifacts are models in the broad sense (i.e., terminal models or metamodels), we think that the main kind of analysis a MDA tool should concern the calculation (and of course visualization) of metrics on models. An MDA tool should provide a set of tools for generating, analyzing and visualizing several kinds of metrics on the different models it produces and/or handles. The semantic of these metrics will depend on the kinds of model that are considered and also on their domain of application. This specific problem has already been mentioned in our answer to question 34.

OMG Request for Information (RFI) MDA Tool Capabilities RFI 20

Glossary

This last section is defines the specific terminology we use within this response. We focus more particularly on the mapping of this terminology to the OMG standard terminology, whenever possible.

Term Definition

Technical Space A model management framework, belonging to the "modeling world", with a set of tools that operate on the models defined within the framework.

MDA is an example of Technical Space. XML and Grammarware are two other examples, based on different technical solutions.

System

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

Model

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.

Terminal model (M1)

A model such that its reference model is a metamodel, i.e. it conforms to its reference metamodel. It is a representation of a "real world" system.

Metamodel (M2)

A model such that its reference model is a metametamodel, i.e. it conforms to its reference metametamodel.

Metametamodel (M3)

A model that is its own reference model, i.e. it conforms to itself.

Working zone

A delimited part of the world (the "real world") consisting of MDE resources.

Transformation

A terminal model that defines a transformation from a model M1 A , conforming to a source metamodel M2 S , to a model M1 B conforming to a target metamodel M2 T . Its reference model is a transformation metamodel (like the metamodel of the ATL language for example).

Megamodel

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 OMG Request for Information (RFI) MDA Tool Capabilities RFI 21

"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.

Zoo

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" 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.

Mirror zoo

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…).

Weaving model

A model that contains relationships between elements of different models. It conforms to a weaving metamodel.

Core weaving metamodel

A core weaving metamodel defines elements that support basic link management, i.e., N:N relationships between model elements.

AM3

ATLAS MegaModel Management AMW ATLAS Model Weaver ATL ATLAS Transformation Language KM3 KM3 (Kernel Meta Meta Model) is a neutral language to write metamodels and to define Domain Specific Languages (DSLs).

MoDisco

Model Discovery component dedicated to modeldriven reverse-engineering (MDRE) TCS TCS (Textual Concrete Syntax) is a DSL for the specification of textual concrete syntaxes.

  Figure 1: General Modeling Framework

  to this. Nevertheless, in practice we are for having tool support for all the previously expressed requirements. What we claim is that any model toolkit should provide model marking or model decoration facilities implementing these requirements. The AMW component of the AMMA platform has proven that implementing these facilities at a low cost is already possible.

OMG Request for Information (RFI)

MDA Tool Capabilities RFI 9

  What types of tools are part of your MDA toolchain? Please refer to the types of tools in the taxonomy, if possible.Within the AMMA Platform, several tools are provided for different purposes. Most of them are fully integrated, as plug-ins, into the Eclipse environment.

OMG Request for Information (RFI)

MDA Tool Capabilities RFI 18

34.

OMG Request for Information (RFI)

MDA Tool Capabilities RFI 3