Where Does "End-to-end" End?   Table of contents   Indexes   Online Publishing using Topic Maps. The Case of Quid Encyclopedia
Bézivin, Jean
 France 
 Nantes 
University of Nantes
 		Jean Bézivin
 Professor
University of Nantes
 2, rue de la Houssinière B.P. 92208 Nantes (Cedex 3, 44322)  France
Email: Jean.Bezivin@sciences.univ-nantes.fr Web site:http://iae.univ-nantes.fr/bezivin/
 Biography
 Jean Bézivin is professor of Computer Science at the University of Nantes, France. He got his Master degree from the University of Grenoble and Ph.D. from the University of Rennes before spending several years, as an assistant professor, at the University of Brest. He also spent a year as a research fellow at the Queen's University of Belfast (Northern Ireland) and later at the Concordia University of Montreal (Canada). Since 1980 he has been very active in Europe in the object-oriented community, starting the ECOOP series of conference (with Pierre Cointe), the TOOLS series of conferences (with Bertrand Meyer), the Objet'9X industry meeting (with Sylvie Caussarieu and Yvan Gallison), and more recently the <<UML>> series of conferences (with Pierre-Alain Muller). He founded in 1979, at the University of Nantes, one of the first Master programs in Software Engineering entirely devoted to Object Technology (Data Bases, Concurrency, Languages and Programming, Analysis and Design, etc.). His present research interests include object-oriented analysis and design, reverse engineering, knowledge-based software engineering, product and process modeling.
 

Introduction

 Within the OMG (Object Management Group) or the Microsoft environment, meta-model technologies are becoming ready for prime time. One of the main enabling factors is that they are now supported by XML-related languages. A number of new possibilities are stemming out from the synergy between these two emerging fields (XML and model engineering), at the conceptual and the practical level. At the source of modern model engineering we find the MOF (Meta-Object Facility), a new emerging OMG standard. The MOF will probably have an important impact on many areas of object-oriented software engineering, as well as on other fields. The MOF is an outcome of the OMG ADTF (Analysis and Design Task Force) and is rapidly gaining practical importance, beyond the UML (Unified Modeling Language), in the industrial strategy of several important companies. Many product definitions, like the UML language itself, are already based on the MOF. Many more are presently being built on a MOF-compliant basis.
 One of the consequences of the aforementioned synergy is the XML-based XMI model interchange format, approved by the OMG in January 1999. XMI is the representation standard for MOF-compliant models and meta-models. In this paper we investigate the new model-engineering scene, both from the conceptual and from the practical point of view. The proposed vision is that there are now two distinct spaces for models: the abstract space and the concrete space. A UML model expressed within a commercial CASE tool is considered in theabstract space while its corresponding projection in XMI will be considered to be in theconcrete space. There are a number of arising questions about this organization. To single out only one of them, we have an open choice of organizing model transformation at the abstract or concrete level. The advantages of choosing the concrete level is that there are many available tools that will greatly facilitate this task, namely those based on the XSLT language. For this to be feasible, we need to guarantee the bi-directional equivalence between models in the concrete and abstract spaces.
 

On Meta-models and Ontologies

 The importance of model engineering in the software development process is rapidly growing [1], [14]. Models are defined (constrained) by meta-models that we shall call synonymously here ontologies. The word "ontology" [7] will be used here in an interchangeable way with "meta-model" for defining a set of concepts and relations between these concepts. An ontology is used as an abstraction filter in a particular modeling activity. From a given system, we can extract a particular model with the help of a specific ontology. If, as an example, the system is a University department, the ontology could have{Teacher ; Student; Course} as its set of concepts and{takes [Student, Course]; teaches [Teacher, Course]} as its set of relations. The model extracted from a given department, with the help of this ontology, may serve to know the students that take more than one course given by the same teacher. The question of how many students in the department play basketball in the same team cannot be answered with the given ontology: a model is being built for a specific purpose; this purpose is usually implicit in the corresponding ontology.
 Therefore, the basic use of an ontology, is to facilitate the separation of concerns. When dealing with a given system, you can observe and work with different models of this same system, each one characterized by a given ontology. Obviously when several models have been extracted from the same system with different ontologies, these systems remain related and, to some extent, the reverse operation may apply, namely combination of concerns. What we need for that is a regular organization of composite ontologies. Before being in a position to propose this organization, we need to get a deeper understanding of the relation between a model and its meta-model. More precisely, the question addressed is about the nature of the information contained in a meta-model and about the exact role played by such a meta-model. The usual view of a meta-model is that it provides the "language" used to define any associated model. Obviously this goes beyond the simple expression of a basic vocabulary.
 An ontology may contain information of different natures. Usually there are three kinds of information (layers) inside a given ontology:
 
  1.  Terminological. This is the basic set of concepts and relations constituting the ontology. It is sometimes called the "definition layer" of the ontology.
  2.  Assertional. This part is sometimes called the "axiomatic layer" of an ontology. It is a set of assertions applying to the basic concepts and relations, e.g.:
     context Generalizable Element
     : self.allSupertypes->forAll(s | s <> self) ;
  3.  Pragmatical. This may be called the "toolbox layer". It contains a lot of pragmatical information that could not fit in 1.) or 2.). For example, if there is a concept ofClass defined in part 1.), then part 3.) could contain the way to draw this concept on screen or paper, as a rounded rectangle for example, with the name inside in bold characters. A number of pragmatical data may be found in an ontology, for example the way to serialize or to make persistent or to pretty print the different concepts and relations of the ontology or an API expressed in IDL. It is of paramount importance that this pragmatic information could be kept packaged and close to the basic concepts it is related to.
 Of course the UML practitioner has already recognized above the UML basic entity level, the OCL statement level and the graphical display level.
 

The MOF: a Knowledge Bus

 After CORBA and UML [12], we may observe now a third wave of proposals at OMG, characteristics of a new period and of a new reaction. At the center of this evolution, we find the MOF (Meta-Object Facility [6], [11]), unique and self-defined meta-meta-model. The MOF will be considered here as a knowledge bus, similar and complementary to the CORBA software code bus.
 One possible interpretation of this is that model engineering is progressively becoming a mainstream technology and that models and meta-models are being recognized as first-class entities in the software development process.
 The MOF has emerged from the recognition that UML was one possible meta-model in the software development landscape, but that it was not the only one. Facing the danger of having a variety of different meta-models emerging and independently evolving (data warehouse [10], workflow [15], software process, etc.), there was an urgent need for an integration framework for all meta-models in the software development scene. The answer was thus to provide a language for defining meta-models, i.e. a meta-meta-model. This is the purpose of the MOF. As a consequence, a layered architecture has emerged, with the following levels:
 
  •  M3: the meta-meta-model level (contains only the MOF)
  •  M2: the meta-model level (contains any kind of meta-model, including the UML meta-model)
  •  M1: the model level (contains any model with a corresponding meta-model in M2).
 Some also consider a fourth layer called M0 for terminal instances, but this will not be used here.
 UML has served as a trigger to introduce the MOF at OMG, in addition to CORBA. Officially, the Unified Modeling Language is a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. For many, UML is much more than that and symbolizes the transition from code-centered to model-centered software production techniques. It is very likely that, in a historical perspective, UML will be given credit for the new perspectives opened as well as for the direct achievements realized as a modeling notation. The mutual relations of UML and the MOF are further discussed in a further section.
 

Towards an Abstract Model Architecture

 As previously described, a framework is being built upon the MOF. This framework is going to have a central place in the forthcoming software development environments. This is why we need to understand clearly the key concepts involved.
 A meta-modeling architecture is an architecture with the three basic properties:
 
  1.  Modular (the modularity should be defined from the start)
  2.  Typed (every entity has a type or concept without any exception)
  3.  Reflective (there is a level of self-definition)
 All the practical proposals more or less implement this. At the top-level of such architecture, there is always a meta-object facility kernel (fixed-point definition space). This should contain at least the three following features:
 
  1.  Entity
  2.  Relation
  3.  Module
 It is unfortunate that many of the practical systems use the word "class" instead of "entity" from the start. Much confusion may result as this framework is intended to take into account different class-based meta-models, each one having in turn its own definition of what a class is.
 The three mentioned concepts are all that we need for a minimal conceptual meta-meta-model kernel. Unfortunately again, the search for minimality has not always been the main criteria for the definition of industrial meta-object facilities. Therefore, concepts that are not always core concepts may be found in basic layers.
 

Some Examples of Meta-Object Facility Systems

 Throughout this paper we mention the MOF, the unique meta-meta-model of OMG. However, in order to be fair and complete, we should also mention that similar meta-model architectures are being used outside OMG. Microsoft is conducting one of the most important efforts, recently sharing them with the Meta-Data Coalition. This section rapidly describes it and shows that the abstract concepts are similar, within a different industrial strategy. The OIM (Open Information Model, [9]) officially aims to support tool interoperability via a shared information model, across technologies. It is designed to encompass all phases of a project's development lifecycle, from analysis through deployment.
 The Microsoft model architecture is also based on a meta-meta-model. It is called RTIM (for Repository Type Information Model) playing conceptually the same role as the OMG MOF. The RTIM proprietary meta-meta-model is implicitly used in the various OIM meta-models. The OIM entities represent meta-models and the links between them defines dependencies. Each meta-model is composed of interfaces and classes. A dependency link from meta-model A to meta-model B means that interfaces in A may inherit interfaces in B or that classes in B may support interfaces in A.
 The nature of Microsoft ontologies is very specific: Uml stands for the initial UML version 1.0 defined at OMG. Umx is Microsoft own extension of UML, taking into account, for example, some extensions of UML 1.1 and later. Dtm is a Data Type Model, a set of Uml extensions for common data types. Cde (Component Description Model) describes generic executable components, Gen a set of general-purpose interfaces, Dbn a set of generic database concepts, Ocl a set of Oracle specific extensions to Dbm, Tfm a description of movement operations on data between databases, etc. Recent agreements between Microsoft and the Meta-Data Coalition could bring more meta-models to this architecture, like a business rule meta-model.
 

Revisiting UML and MOF Relations

 On very practical grounds, UML is considered, at level M3, as a drawing tool by MOF practitioners, i.e. by designers of meta-models. More precisely, the MOF is also structurally similar to the kernel of UML, the CORE package. There is no theoretical reason for this. It is just more convenient: no need to define new tools to draw meta-models: the UML tools, mainly intended to support the design of UML models could as well be used in support of MOF meta-models. Note however that the design of meta-models is an activity much less frequent than the design of UML models; furthermore it is an activity performed by a more limited and specialized population.
 UML is a practical tool now but it has also served as an experimentation platform. As previously mentioned, the self-definition of UML was an interesting exercise and was successful per se. However, it also demonstrated that the applicability of this technique could be made broader than just the handling of software artifacts. Consequently, a new architecture was defined around the MOF. This architecture is complex and still evolving, but it could be compared to CORBA by its central role for defining OMG recommendations.
 The MOF uses UML in various ways, for example for graphical presentations. However, the main difference is that the MOF and UML are not at the same level in the OMG architecture model. The MOF is a meta-meta-model and is at the level M3 while UML is a meta-model and stands at level M2. The MOF is a language for defining meta-models and UML is just one of these meta-models. Other meta-models that are being defined at the level M2 are for example related to common warehouse, workflow, software process, etc.
 UML has been instrumental in triggering the development of a new modeling architecture based on the MOF. Many ideas have been successfully tested on UML and then transferred to the MOF because they were found to be of broader applicability. The first one is the OCL (Object Constraint Language [16]). OCL is an expression language that enables one to describe constraints on object-oriented models and other artifacts. The word constraint is used here with the meaning of a precisely identified restriction on one or more values of a model. We see here a pleasant property of the global OMG modeling architecture. Since a meta-meta-model is structurally similar to a meta-model, features applied to one may also be applied to the other one. Therefore, OCL, which could be applied to meta-models to give more precise semantics to models, could also be applied to meta-meta-models to give more precise semantics to meta-models. This is exactly what happens when OCL is applied at the MOF level.
 Another example is the answer to the SMIF RFP ("Serial Model Interchange Format" Request For Proposal) of the OMG [13]. Initially the purpose of the Stream-based Model Interchange Format was mainly to exchange UML models. As it has finally been issued, answered and approved, the proposal is being known as XMI, a new standard for Meta-data Interchange based on XML and on the MOF. Once again, there is nothing to loose, if by providing a technical solution to a specific UML problem, it is possible to provide a more general solution that could be applied to the UML meta-model, as well as to other meta-models already defined or yet to be proposed. XMI is now a standard way ofexchanging any kind of models and meta-models.
 Many more examples could be given of this trend. There are for example several demands to provide structured extension mechanisms for UML, going beyond single stereotypes, tagged values and constraints. Requests are being submitted for specialized UML-based meta-models on subjects like real-time or business objects. A possible answer to this would be some notion of profiles. In the case where this improvement is allowed to the UML meta-model, there is no reason that the other MOF-compliant meta-models should not also benefit from the added modular modeling mechanisms. A UML profile may be defined as a subset or a superset of the basic meta-model. There is however no agreement yet on the way this notion of a profile could be defined (restriction profiles, extension profiles, combination of profiles, etc). When a general solution to this problem is found, then we may envision important hierarchies of meta-models, allowing a good compromise between standardization and openness.
 

On the Duality of Model Spaces

 It is interesting to remark that two independent technological evolution movements are now reaching a meeting point. On one side, applied model engineering has much matured in the last ten years. The proposals of the UML and the MOF have been made in a very short period of time and correspond to a strong and urgent demand from the software engineering industrial community. On the other side, the story of HTML, XML and XSL is now well known and these technical solutions have emerged at the same time in different places, for different needs.
 One important step was made when it was observed that the relation between an XML document and its DTD was somewhat similar to the relation between a model and a meta-model or between a meta-model and a meta-meta-model like the MOF. XMI may be seen as an outcome of this observation.
 It is common now to think about a model expressed either in a given abstract syntax or in a concrete syntax. A UML graphical model for example may be considered to be expressed in an abstract syntax. The new situation arises from the observation that XML has now become the common denominator for concrete syntax. The consequences of this are tremendous and the synergy between the XML technology and the model engineering technology is likely to increase rapidly.
 The merging point between these technological families is being concretized by the XMI proposal. However all of the consequences of this merge are not yet completely understood. In some cases we have not yet seen the full impact of the synergy. In other cases we may face some confliction situations when each family has its own vision of a specific aspect and when these visions conflict. We give below a short list of some points that we are presently investigating.
 
  •  Issues of presentation. This is yet an open question in model engineering. In CDIF technology [2], there were explicit and separate meta-models (subject areas) for graphical presentation of models. The idea has not been pursued as much in the UML/MOF technology. As a consequence we deal more with logical models and it is not always easy to store and retrieve the graphical placements of boxes and links in a given model. On the other side, this may be fortunate because it will give a chance to think about using solutions like DrawML for example for graphical presentation of all kind of models.
  •  Issues of transformation. This is a hard issue but a very challenging one. For many the procedure refinement paradigm represents the past technologies, the object composition represents the present technologies and the model transformation represents the future technologies. Model transformation has been presented as the central technology of future approaches in software engineering. The fact that any model is now based on an explicit meta-model facilitates the rigorous expression of transformations. The support for systems of transformation will find its natural place in the MOF, since a transformation involves by definition several meta-models. But here again the XML family of technologies has made important progresses in this field in the recent period. So we are faced with abstract transformation that could be expressed in the context of the MOF and concrete transformation that may be expressed in the context of XML. There is no yet any agreement to express transformations in the abstract space while there is not only syntax but also available transformation engines based on XSLT in the concrete space. In order to be able to implement an abstract transformation at from model ap to model aq in the abstract space, at(ap,aq) we should be able to find the corresponding transformation ct in the concrete space, from concrete model cp to cq: ct(cp,cq). If we note aTc(ap,cp) the abstract to concrete model transformation (e.g. from graphical UML to XMI), then we can see that we still need the inverse transformation from concrete to abstract if we wish to implement the complete transformation: cTa(cq,aq). What will remain to do will then be to find a system for transforming abstract transformation in concrete ones, i.e. a mapping ?(at,ct). Obviously the ct transformation will be expressed in XSLT.
  •  Issues of transport. . This is mainly the domain of XMI, i.e. serialization of models and meta-models. XMI is the standard for transporting all sorts of models and meta-models. "All sorts" means any kind of MOF-compliant model. As a consequence the problem of the scope of the MOF appears here. Should the MOF architecture be reserved to the software engineering field? Open to the information-modeling field? Open to any other field? The answer is more strategic than scientific. But the consequences will be important on the kind of models XMI will be able to transport. As one example, one may think of the role of OCL in the definition of XMI. What will be the meaning of XMI for the transport of models not based on a MOF-compatible DTD for example?
  •  Issues of generation. . This seems an issue that has not been much pursued on the XML side. It is related to transformation, but the target is a given middleware (e.g. CORBA) or another system of APIs. There seems to be no major problem in this area and the synergy that will allow going from DTD-based XML files towards IDL definition or business data for example is an interesting technological lead.
  •  Issues of modularity. . This is probably the most critical aspect of the technology merging. As a matter of fact both technologies have an evolving idea of their needs in terms of modularity. On the XML side, the Namespaces recommendation allows element type names and attribute names to be qualified by a URI, but it would be useful to associate each URI used in a universal name with some sort of schema and to be able to validate a document using multiple such URIs with respect to the schemas for all the URIs. The problem is thus to improve DTDs with a new schema mechanism providing namespace-awareness. On the model engineering side, the situation is not much better. When UML was defined by the OMG, a proposed schema definition was not introduced in the standard. Today the concept of package is used both at the UML and the MOF level. The present debate on the concept of meta-model "profiles" is directly related to this and the modularity features provided by the package mechanism alone is not sufficient for solving the immediate needs. So there is no much hope of a convergence in this area since the needs of each community are different in the domain of modularity. We may hope that the final solutions adopted on each side will not be in total contradiction.
 

Conclusion

 The move from procedural technology to object technology may have triggered a more radical change in our way of considering information systems and of conduction software engineering operations. One of the considered evolution path is called model engineering. It consists in giving a first-class status to models similarly to the first class status that was offered to objects at the beginning of the object technology era.
 The promises for unification and simplicity initially made by object technologists in the late eighties seem to have fallen short. When we consider today the task of building a system from components, it is at least as complex as it was with the previous technology. Taking into account a lot of new software attributes (e.g. QoS attributes) is making this task even more difficult. It is becoming obvious that we need some solution to cope with this rapidly increasing complexity.
 The recognition of multiple, co-existing meta-models is an important step forward in software engineering and information technology. That means that at some given point in time, an engineer may be dealing with several models (i.e. a Java model and an UML model), all of them defined by a precise meta-model, and all of these meta-models based on the same meta-meta-model. A similar software process meta-model may also describe the action undertaken by this engineer. As a consequence, model engineering may become a transition as important as object technology for the software industry.
 The transition to model engineering has been rapid in the last period, characterized by the adoption of the UML and the MOF. It has recently been enforced with the help of the XML technology family. Initially targeted to document handling and to Web-support, XML is now giving a high momentum to the whole field of model engineering. Once some problems like modularity will be solved, the application domain of the joint technologies is likely to broaden rapidly.
 

References

 
  1.  Atkinson, C. Supporting and Applying the UML Conceptual Framework. International Workshop <<UML>>'98, Beyond the Notation, Mulhouse, France, June 3-4, 1998, Springer Verlag LNCS 1618.
  2.  Atkinson, C. Supporting and Applying the UML Conceptual Framework. International Workshop <<UML>>'98, Beyond the Notation, Mulhouse, France, June 3-4, 1998, Springer Verlag LNCS 1618. Bézivin, J., Ernst, J. & Pidcock, W. Model Engineering with CDIF OOPSLA'98, Vancouver, post-proceedings, Summary of the workshop, October 1998.
  3.  Bézivin, J., Lanneluc, J., Lemesle, R. Representing Knowledge in the Object-Oriented Lifecycle TOOLS PACIFIC'94, Melbourne, December 1994, Prentice Hall, pp. 13-24.
  4.  Bobrow, D.G. & Goldstein, I.P. Representing Design Alternatives Proc. Conf. on Artificial Intelligence and the Simulation of Behaviour, Amterdam , July 1980.
  5.  Chandrasekaran, B., Josephson, J.R., Benjamins, V.R. Ontology of Tasks and Methods, 1997 AAAI Spring Symposium and the 1998 Banff Knowledge Acquisition Workshop 1998.
  6.  Iyengar, S. A Universal Repository Architecture Using OMG UML and MOF, EDOC'98, La Jolla, Ca, 2-5 November 1998.
  7.  Kayser D. Ontologically Yours Invited Talk, ICCS'98, Montpellier, France, LNAI #1453, M.L. Mugnier & M. Chein Eds, August 1998.
  8.  Kruchten, Ph. The Rational Unified Process : An Introduction Addison Wesley, 1999.
  9.  Microsoft, Microsoft Repository Product Information, Open Information Model Overview, 1999.
  10.  OMG/CWMI Common Warehouse Metadata Interchange Request For Proposal, OMG Document ad/98-09-02, September 18, 1998.
  11.  OMG/MOF Meta Object Facility (MOF) Specification. AD/97-08-14, Object Management Group, Framingham, Mass., September 1997.
  12.  OMG/UML Specification. Version 1.3R9, Rational Software, January 1999.
  13.  OMG/XMI XML MetaData Interchange (XMI) Proposal to the OMG OA&DTF RFP3 : Stream Based Model Interchange Format (SMIF) Document ad/98-10-05, (October 20, 1998), Adopted at the Washington Meeting, (January 1999).
  14.  Raymond, K. Meta-Meta is Better-Better. IFIP WG 6.1 International Working Conference on Distributed Applications and Interoperable Systems, September/October 1997.
  15.  Schulze, W., Böhm, M., Meyer-Wegener, K. Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments, OOPSLA 96, Workshop on Business Object Design and Implementation, San José, CA.
  16.  Warmer, J., & Kleppe, A. The Object Constraint Language Precise Modeling with UML Addison Wesley, October 1998.
Where Does "End-to-end" End?   Table of contents   Indexes   Online Publishing using Topic Maps. The Case of Quid Encyclopedia