This position paper describes the sBrowser, a tool that we have used for more than five years for dealing with all kinds of models, meta-models and meta-meta-models. It is based on the formalisms of sNets, a kind of minimal representation system, similar to CDIF or the MOF. We present the corresponding tools in this workshop because we believe they could be used as well with other formalisms. The starting point is that we needed a general workbench for our needs of model engineering. First conclusions showed that a graphics-based drawing tool would be unusable and hence useless for manipulating graphs of more than several hundred nodes. Since the size of our graphs were at least one order of magnitude more, we had to propose a more suitable set of tools. In the end of the paper we show how we however reintroduced graphics presentation for very particular tasks. From the sBrowser prototype, the concept of a meta-browser has progressively emerged. It is mainly a browser that allows to navigate in various information spaces under the control of different meta-models.

Browsers; Meta-Browser; Model engineering; sNets; CDIF; MOF; Ontologies; Meta-modeling; Semantic interoperability;

In a very short period, the OMG has seen the emergence of a second interoperability bus (Figure 1). The first one, the well known CORBA software bus with its IDL interface language, with its various language mappings (Java, Cobol, C++, Smalltalk, etc.), with the IIOP protocol, etc., has become the norm when talking about middleware and circulating software.

The second OMG interoperability bus, more recently born, is called the semantic bus. It has still a fragile definition and structure. If we wished to characterize it, we would use words like MOF, UML, OCL, CDIF, XML, XMI, SMIF, etc. It is not yet completely stabilized, but it is gaining rapid recognition both inside and outside the OMG. This rapid recognition has been prepared by a long and obscure preparation work, the most important being the ten years progression of the CDIF community, seeing today its accomplishment in the recognition of the meta-modeling importance, probably soon to belong to the software production main stream.

So what is this semantic bus useful for and how is it organized? We are dealing with the three basic concepts of models, meta-models and meta-meta-models. All of these may be called ontological spaces. They are related by very specific relations that are based on the concepts of the MOF (Meta-Object Facility [Crawley 1997], [Crawley 1998]). An entity in a model finds its definition as a meta-entity defined in the corresponding meta-model. A meta-model constrains a model in the sense that it contains all the concepts used in the model.

More and more the emergent software component technology makes use of a lot of different models and associated meta-models. We see a lot of coding models, architecture models, domain models, requirement models, deployment models, measurement models, etc. There is obviously a need to have composite models (i.e. models composed of several other models), and derived models (i.e. models using more concepts and relations than their base model). Each of these models is defined (constrained) by a specific meta-model.

Figure 1: OMG, the two cultures : software bus vs. semantic bus.

So a meta-model is composed of concepts and relations. We have argued elsewhere [Bézivin 1998] that such a meta-model is an ontology with its three layers : terminological, axiomatic and pragmatic. In the terminological layer, the concepts and the relations that may hold between these concepts are defined. In a MOF-like top layer ontology (a meta-meta-model), three basic entities exist : link, node and space. This corresponds to some kind of lexical entities that will allow to build up later on any kind of complex meta-model.

Of course, if the importance of model engineering in software engineering is being more and more recognized, we need suitable tools to deal with these models, meta-models and meta-meta-models.

The tool we have been using took initial inspiration in one of the earlier Smalltalk projects developed at the Xerox PARC lab, in the early seventies, by Dan Bobrow and Ira Goldstein. The name of this project was PIE (for Personal Information Environment) and it has still many features, in the domain of software configuration and versioning, that have not found fair development recognition in today's industrial deployment. PIE was implemented at that time in Smalltalk-76.

Within the ongoing Osmosis project at the University of Nantes [Bézivin 1995], many successive versions have been built and used since 1990, based on the ideas of PIE, but with the ultimate goal of producing tools for software development and model engineering. After several design iterations on three years, the tool took the name of sBrowser for semantic browser. As part of an industrial transfer (ANVAR), the tool and basic concepts have been later transferred, on a non exclusive basis, to the Softmaint Company in order to built a reengineering workbench for tracking year 2000 problems in Cobol software. The reengineering tool is today marketed by this company under the name Semantor. One important investment of the company has been to define meta-models for various kinds of non-object spaces like COBOL'85, RPG 3, SQL, etc. At the same time we are still working on the sBrowser as a basic tool for model engineering. The sBrowser is a meta-browser that allows to work at the model, the meta-model or the meta-meta-model layer in a completely transparent way. It is strongly linked to the architecture of sNets [Bézivin 1994], our own Meta-Object Facility system, based on a particular brand of typed, reflective and modular semantic networks. The sNets can be compared to a very elementary version of Sowa's conceptual graphs.

The latest state of the tool is illustrated by Figure 2. It shows two rows of information with a dynamically variable number of columns. This is our exploration and intervention window on a directed labeled graph that may be huge (i.e. on the order of 10⁶ nodes). It is the basis of our meta-modeling workbench in the Osmosis project. The main ideas of the meta-browser technology can be summarized as follows:

1. Graphical browsing becomes useless above 500 nodes graphs. Performance improvements based on zooming, eyefish or other technical tricks have not been able to extend the usability of the tools when dealing with real-size models of more than 10.000 nodes.
2. Hypertext based systems allow an improvement on scalability, specially if they are Web-based. However they suffer of a lack of precise definition of the semantics of links and nodes on which they apply. Moreover the notion of modularity is not always completely taken into account.
3. What the model engineer actually needs is some kind of minimal uniform tool to deal with all kind of models, meta-models and meta-meta-models. This tool should be adaptable and extensible. The specialization of the tool should be made possible under specific contexts.
4. At any time, the engineer is viewing information under the constraint of a specific meta-model. This is the basic ontologic principle of the meta-browsing technique.
5. The graphical drawing view should be considered as a secondary help. In the example of Figure 2, the engineer is working on a particular UML model within the sBrowser. If, at anytime of the work, he/she needs to have a graphical presentation of the current viewing context, he/she can ask for it, with the graphical UML drawing conventions, stored in the UML ontology. The terminological data will be the same but the presentation will change. Switching between different presentations of the same basic information is an important property of meta-browsers.

Figure 2: General presentation of the sBrowser.

In order to give a clearer presentation of the meta-browsing technique, let us start with an ordinary (non-meta) browser. We shall take as an example one of the first browsers that appeared on the technological scene in the seventies, namely the Smalltalk browser. Figure 3 presents an image of this browser with its 5 panes. In the upper row we first find the categories of classes^{[Note 1]} (Collections-Abstract selected). Then, related to the selected category, we find all the classes of this category (class Collection selected). Immediately on the right, there is the protocol pane. A protocol is a set of methods associated to a given class (protocol adding selected here). On the last pane on the right, all the methods belonging to protocol adding of the class Collection of the category Collections-Abstract are listed (method addAll: selected). Finally, in the lower pane, we find the text of the method addAll:. In addition to the five panes, there also is a switch below the second pane of the upper row that indicates if we are operating at the class or at the meta-class level. We will have completely described this browser when we say that a number of pop-up menus may appear when clicking the mouse, function of:

1. which of the mouse buttons we clicked (red/left, yellow/middle, blue/right)
2. which pane was the cursor inside when clicking
3. which elements were selected when clicking

[Note 1: In Smalltalk-80 categories are groups of classes. They are more limited than packages in Java for example because a category contains only classes and no other category. Also they are a partition on the global space of classes since a class may only belong to one category. endOfNote]

We will not go over all these presented details here. Our goal is to make clear that this is a hard wired specific browser for a particular kind of meta-model. The meta-model is described below in a sNet like notation:

Table 1: A partial meta-model (ontology) for the Smalltalk environment.

Figure 3: A sample of Smaltalk-80 browser.

The Smalltalk-80 programmer nearly always work with this browser to understand the several hundred of classes present in the basic Smalltalk library, or to build new classes. He/she works under a specific context, always the same. He/she is browsing under the constraint of a given ontology (or meta-model) called here Smalltalk_Sem.

On the contrary of this approach, the idea is to allow the model engineer to use any kind of meta-model, i.e. to dynamically switch between one meta-model and another one at any moment. This is becoming an essential feature of advanced workbenches. In earlier time each person was mainly using one model at a time, i.e. either programming in a given language or constructing SADT models, etc. Now it becomes common that an engineer may be looking at the same time to a UML and a Java model for example^{[Note 2]}. He/she may be jumping from a technology based view to an enterprise-based view. Having a tool that will reflect the basic definitions under which he/she is operating at any time and will allow smooth changes of context will be a great achievement.

[Note 2: This is becoming a real concern to have such an important number of so called "object semantics", i.e. meta-models that are similar but subtly and significantly different. The notion of a class in Java is related to the notion of a UML class but it is not the same. endOfNote]

In order to make this possible, the state of the art had to reach a certain level. Now, with progresses made on CDIF, the MOF and more generally on the OMG semantic bus apparatus, this level has been reached and we may consider moving from the terminal browser technology (i.e. a browser perhaps sophisticated in its functions but hard-wired to a specific meta-model) to a meta-browser i.e. a browser with integrated intelligence that will allow to adapt to any kind of meta-model viewing and updating. The sBrowser is a prototype for such kind of tools that will be central to the modeling workbench in software and other product and processes modeling tasks.

Of course, one enabling technology that will booster the use of the meta-browser is the existence of a standard serialization format. This is now well underway with OMG efforts at the MOF level on SMIF and XMI.

Figure 4: Accessing the meta-model layer.

The rapid and convenient switching from one context to another one, in an ontology-driven meta-browser may have a lot of applications. We discuss below some of these new possibilities.

1. It is possible to switch up and down at any time from model to meta-model and then from meta-model to meta-meta-model. This is just like following an internal link^{[Note 3]}. An illustration of this may be found in Figure 4.
2. It is possible to switch from a model to a sub-model, i.e. to a simplified view offering a synthesis. The work will have to be done. at the meta-model. An example will be to hide some of the concepts and relations in a given model.
3. It is very easy to extend the models by light modification of the meta-model. One example would be to associate comments to some entities.
4. It will become easy to develop model checking and model transformation algorithms [Lemesle 1998, EDOC].

[Note 3: Of course anyone will not be able to modify any information, for example inside the meta-meta-model layer. Authentification information may be attached to the pragmatic level of any ontological space to specify access autorisation. endOfNote]

We promised earlier to show how a graphical drawing view may be presented as an alternative to the user. Here is the view corresponding in part to Figure 2. The user may switch from Figure 2 to Figure 5 and back without any problem.

Figure 5: Graphical view corresponding in part to Figure 2.

Finally we can't finished talking about the meta-browser without mentioning actions and pop-up menu triggered actions. The way it is solved is very uniform. As any meta-level data, this information is stored in ontological spaces, specifically into the pragmatics layer of the ontology. It is stored as any other data. To a concept node, one or more when links may be attached. These links lead to an Action node, representing a triggerable action. The Action node itself has a what link leaving it and going towards a String node. This string is interpretable by the underlying machine. It may be a Java, Javascript, Python, or any kind of executable program. We have not yet definitively settled the script language that will be used to define semantic actions, waiting the conclusion of the scripting language RFP at OMG. Historically, in the first versions of the sBroser, our scripts were all written as Smalltalk-80 blocks. The notion of Smalltalk block (a closure) corresponded exactly to our needs. Since the translation of the sBrowser from Smalltalk to Java, this problem is waiting a definitive solution.

Figure 6: Popup menus appearing in a meta-browser.

So, the originality of the approach is that the actions are stored, in a competely uniform way, in the meta-model itself and associated to the concept. When an element corresponding to this concept is selected, the corresponding menu appears in the meta-browser, with a list of choices. This list of choices corresponds to the various attached Action nodes. These Action nodes have an executable facet, as a matter an interpretable String field. As we said above, the scripting language is still awaiting a definitive solution. Initial use of these devices at the Softmaint company, as an action language to express propagating operations on the different nodes of Cobol models has proved a highly useful mechanism. It is based on a defined minimun API for accessing the different nodes of the sNet.

We have presented here a specific tool that has been used in the last years at our lab for model engineering. This is a meta-browser, intimately linked to the meta-level architecture of the sNet representation formalism. We are convinced that this prototype could be used as well to engineer model written on other platforms and with other formalisms like CDIF or the MOF or even Conceptual Graph based systems. The condition is to have a well defined modularity notion (space, universe, context, subject area, package, etc.) used to separate the meta-modeling layers. If this is the case, and if the modularity concept is well integrated, then the meta-browser technology can be appliedwith success.

The main proposal contained in this paper is not related to a display/browsing technology. On the contrary, what we have argued is that the emergence of a mature model engineering field, based on a clear and clean separation of meta-models, will need corresponding tools.