Modelling consists in representing increasingly complex information like data and processes descriptions. So, modularity is an essential concept in modelling. Without modularity, such set of information may be totally unusable. Then, meta-modelling is only a kind of modelling and modularity is needed in order to represents meta-models too.

Modularity can be used for several purpose :

• used to group elements (model elements, meta-model elements, as meta-meta-model elements)
• may be used for classification (group modelling elements in different subject areas, etc…)
• may allow the representation of the extension of such groups (ability to describe a group as an extension of an other group)
• may allow nesting of such groups (in order to clarify organization)
• may allow the representation of the dependencies between such groups (ability to describe the fact that elements defined in a group may rely on elements defined in an other group)

A meta-model is used to describe models, so a meta-meta-model is used to describe meta-models. The concepts defined in a meta-model are depending on the concepts used in the model. In order to represent an object model, we must use a meta-model which defines concepts such as Class, Object, Inheritance, Method, etc... But if our aim is representing a petri model, we must use a meta-model which defines concepts such as places and transitions.

Then, our aim here is representing meta-models, so we need concepts such as Concept also known as Meta-Entity , and Relationship also known as Meta-Relationship. To simplify meta-model descriptions, other concepts may have been added in the meta-meta-model. These concepts are usually modularity and inheritance for concepts and relationships.

Meta-meta-modeling is usually used to represent several meta-models. Then, modularity is an essential way to clearly identify each of these meta-models and to allow their extensions.In order to be used in meta-models, modularity concept needs to be defined in the meta-meta-model.

The OMG is defining several different meta-models such as an Object Analysis and Design meta-model which is described in the Object Analysis and Design facility and a Workflow meta-model described in the Workflow management facility. So, the need for a common formalism in order to express these meta-models appears. The Meta Object facility has been created to define such a formalism. And the MOF submission has been submitted to the OMG organization to fulfill this request.

So the modularity concept used in UML meta-model must be defined in the MOF submission. It must be said that the UML meta-model has been defined before the MOF. It has not been defined using the MOF semantics, but using the semantics it defines itself. So, a subset of UML semantics has been used as meta-meta-model for describing complete UML semantics. But this subset has not been clearly identified. And now, the MOF is supposed to be the UML semantics meta-model. This may explain why there is so many similarities between the MOF and UML (is that a good thing ? Since it makes sense to define a Class concept in the UML meta-model in order to define classes in models, does it makes sense to define a Class concept in a meta-meta-model ? ).

Modularity in the MOF is obtained by the concept of name spaces (namespace) [ MOF, chap 3.7.2]. A namespace corresponds to a container for a set of modelling elements identified by their names. Moreover, one modelling element may be defined in one and only one namespace.

This means that there is no general modularity mecanism which can be used to group unnamed elements.

A namespace is an abstract concept. Indeed, regrouping modelling elements in MOF is done using the Package concept. But a class, an association and a data type are name spaces too. For example, the namespace of a MOF attribute is its class.

Being given that a class, a package, an association, etc... , are namespaces, it's necessary to define constraints to specify which namespace can contain which kind of modelling elements. Such constraints are defined in the MOF using the OCL language [OCL1997].

Modularity in the MOF is represented by the Package concept [MOF1997, page 3-61] :

The term model used here must be seen as meta-model since it's a MOF definition and MOF models are meta-models (for example, UML meta-model is a MOF model). The last sentence means that a meta-model (which is a package) doesn't have intances. So, the relationship between a model and its meta-model isn't represented using the MOF meta-model.

Package and Namespace definitions in the MOF are the following one [MOF1997, page 3-12] :

figure 1 - MOF definition of Packages and Namespaces

A model element may be contained by a namespace, but can't be contained by several namespaces.

So, a namespace contains a set of model elements. For example, a class is a namespace which may contain features (features are model elements), and a package is a namespace which may contain classes (classes are also model elements).

Generalization and specialization are defined for namespaces and means extension of the name space. To specialize a class may consists in extending its namespace with new features. While to specialize a package may consists in extending its namespace with new classes.

A generalization can only be done if the added elements have different names from those existing ones. In order to express that, there is two OCL constraints [MOF1997, p 3-30] :

[4] GeneralizableElement

self.allSupertypes->

forAll(s | s.contents->forAll(superC | self.contents->

forAll(selfC | superC.name.toUpper <> selfC.name.toUpper))))

and

[5] GeneralizableElement

allSupertypes : Sequence(GeneralizableElement)

-- defines a specific order

allSuperTypes = self.supertypes->

collect(s | { s }->union(s.allSupertypes))->asSet->asSequence

-- convert to set and back to sequence removed dups and preserve order

-- alternatively, express as the sequence minus the intersection of

This effectively means that there is no way to define in a namespace a model element which have the same name that an inherited model element. But this doesn't solve the problem of multiple inheritance. These constraints allow multiple supertypes which define model elements with same names.

So, modularity in MOF is defined using packages which represents set of modelling elements (and cannot contains anything else). Extension is defined for packages in order to extend the content of a package. Such extension can be multiple. But a package cannot contain two modelling elements with same names.

CDIF formalism is composed of a CDIF meta-meta-model and a CDIF Integrated Meta Model.

The CDIF meta-meta-model is used as meta-model for the CDIF Integrated Meta Model which is composed of several subject areas.

Modularity in CDIF Integrated metamodel is represented by the concept of Subject Areas which is defined in the CDIF meta-meta-model [CDIF1994, chap. 3.4.1] :

The subject area definition is the following one [CDIF1994, chap 7.5] :

figure 2 - SubjectArea definition in the CDIF meta-meta-model

Subject areas are sets of meta-entities. And these meta-entities usually appears in several subject areas. Defining a meta-entity in a subject area is done by creating a "CollectableMetaObject.IsUsedIn.SubjectArea" relationship between the meta-entity and the subject area. And later, when a subject area needs to reference a meta-entity defined in an other subject area, the same thing is done : a "CollectableMetaObject.IsUsedIn.SubjectArea" relationship is created between the new subject area and the previous meta-entity. This means that there is no way to know where a meta-entity has been defined first.

Extension mecanism for subject areas doesn't exists in the CDIF meta-meta-model.In fact, extending a subject area is done by defining a new subject area which references all the meta-entities defined in the first one.

Subject areas are not namespaces. Every meta-entity is identified by a unique attribute called CDIF meta identifier. Same thing is done for entities. Every entity is identified by a unique attribute called CDIF identifier.

A subject area isn't a collectableMetaObject, so there is no way to represent nested subject areas.

sNets is based on semantic networks where nodes are typed. The concepts used are Node to represent a type of node and Link to represent a type of link. In this article, we'll employ the term Meta-Entity instead of Node (same role) , and Meta-Relationship instead of Link (same role too). There is also a root type called Root which is the root of the type inheritance hierarchy. In this article, we have choosen to rename it Entity which means that all thing represented in sNets formalism is an entity.

In sNets, a concept called universes is used for modularity [sNets1998] :

Relationships between universes and entities are defined using the following scheme [sNets1998]:

figure 3 - sNets definition for universes and entities

A universe is an entity which means that nesting is allowed for universes. sNets universes are typically used to represent models, meta-models, as well as meta-meta-models. Extension is also defined for universes [sNets1998] :

In sNets, a universe can group elements whatever their names. A universe isn't a name space as in the MOF submission. The only constraint for contained elements is that they must follow the semantics of the universe which is not a name space constraint but more a modelling constraint [sNets1998] :

This is one of the main differences between sNets and other formalisms. In a sNet :

• every model (represented by a universe) must have a relationship called "sem" to its meta-model (represented by a semantic universe which is a subtype of universe),
• every entity must have a relationship "meta" to its meta-entity and
• every entity is defined in a model and must have its meta-entity defined in the corresponding meta-model.

This is represented in the following figure :

figure 4 - models and meta-models relationships.

In other formalisms, there isn't such relationships between models and meta-models. When these formalisms are used, you are only working at one modelling level at one time and only models from that level can be handled. When sNets are used, you must have all these levels represented in sNets formalism in order to handle a model. This means that you must have the sNet representation of a meta-model in order to use a model which follow this semantics. And you must have the sNet representation of the meta-meta-model in order to handle the meta-model.

We will present here how modularity is used in meta-modelling. These three formalisms are reflexive, so the meta-meta-model can also be seen as a meta-model and follows the semantics it defines. We will describe how modularity is used in both meta-meta-model and meta-models.

Modularity is defined in meta-meta-models to be used in meta-modeling.

The choice of the UML meta-model in this article has been done because it is supposed to be a MOF model [UML1997, chap. 2.2] :

The UML meta-model is composed of three packages :

• a foundation package,
• a model management package and
• a behavioral elements package

The UML meta-model is defined using the following scheme [UML1997, chap. 2.3] :

figure 5 - top level packages of the UML meta-model.

In the UML meta-model, there isn't one, but three top level packages. So the entire UML meta-model isn't described within a single package. This means that the meta-model of an UML model is not represented as a single package, but as several packages.

The UML meta-model makes a huge use of nested packages and dependence's relationships. This clearly show the importance of such concepts in meta-modelling.

The CDIF integrated meta-model is composed of different subject areas as following :

figure 6 - CDIF Integrated Meta-Model organization

Every meta-entity defined in the CDIF integrated meta-model must be a subtype of the RootClass meta-entity defined in the Foundation Subject Area. And every meta-relationship must be a subtype of the "RootClass.IsRelatedTo.RootClass" relationship defined in this subject area too. So, every subject area must rely on the Foundation Subject Area. But such dependence's relationships represented here cannot be described in CDIF formalism.

In fact, the following scheme is more accurate since a collectable meta object can be used by several subject areas :

figure 7 - CDIF Integrated Meta-Model organization viewed as sets

And concerning the nesting of subject areas, there is no way to express nested subject areas using CDIF.

a sNet is a universe called World and sNet meta-models are also represented by universes in the World universe. In the following scheme are represented the meta-meta-model called Semantic Universe, the root of all meta-models called CommonSem universe and several examples of meta-models (UML semantic universe which is a universe which represents the UML meta-model, UML semantic extension Universe, which represents an extension of the UML meta-model and Petri Semantic Universe which is a universe representing the Petri meta-model) :

figure 7 - a sNet which contains several meta-models.

Relationships represented here are extension's relationships. These relationships can act as dependence's relationships. In sNets, in order to make a reference to something which is contained in an other universe, you must use the extension relationship. Nesting of universes is allowed.

If the meta-meta-model is reflexive, the modularity concept it defines may also be used in the meta-meta-model.

There is only one package in the MOF. This package is called "MOF model" and contains all the meta-entities defined in the MOF submission.

In CDIF, there isn't any subject area representing the CDIF meta-meta-model. So, concepts defined in this meta-meta model cannot be referenced by other subject areas. And there is no way to extend this core meta-meta model.

In the sNet formalism, the meta-meta-model is defined in a semantic universe called "semantic". So, this universe can be referenced and extended within the sNet.

The package definition described previously exists in the MOF and can only be used in OMG meta-models described using the MOF. There isn't any general mecanism to address modularity problem. In order to have a package concept usable in an model, this concept must be defined in the corresponding meta-model (which follow the semantic defined in the MOF).

So, the Package concept must be defined in the UML meta-model in order to be used in UML models. This concept is defined in the following figure in the UML meta-model [UML1997, chap. 12.2] :

figure 8 - UML meta-model definition of Packages and Namespaces

The package notion described here has no relation with the package notion described in the MOF except the fact that both concepts are used for modularity.

If an other meta-model is defined and needs to address modularity in models, this meta-model would have to define a "package" concept (which of course may be called differently).

Subject areas means nothing for CDIF models. Modularity in a model must be defined in the subject area which defines its meta-model. There isn't any general mecanism to address modularity problem. Within CDIF formalism, a model is described in a file. But there is no way to express that a model (described in a file) is an extension or rely on an other model (described in an other file).

Modularity in sNets is defined in a universe called commonSem as defined in the following scheme :

figure 9 - modularity definition in sNets.

Then, every meta-models (or semantic universes) in a sNet are extensions of this universe. So, the meta-meta-model as well as all other meta-models (the meta-meta model is also a meta-model) are extending the commonSem universe. The only semantic universe which is not an extension of the commonSem universe is the commonSem universe itself.

This makes the concept of universe available in every models (and consequently in every meta-models and meta-meta-models) :

figure 10 - "semantic" meta-meta model and UML meta-model which extend CommonSem meta-model.

This figure shows that the meta-meta model called "Semantic Universe" and the UML meta-model are extensions of the commonSem meta-model. So, models are represented as universes, meta-models are represented as universes (semantic universes which is a subtype of universes) and every entity represented in our formalism is indirectly an "instance" of the Entity concept defined in the CommonSem universe.

In CDIF, every model entity is indirectly an "instance" of the RootClass concept. In sNets, meta-entities are also entities, so we can say that everything represented in sNets is indirectly an "instance" of the Entity concept. This means, for example, that the file-based format which has been defined can represent models, meta-models and meta-meta-models using the same syntax because it only relies on the universe concept and the entity concept.

A meta-meta-model always defines the same concepts :

• the "Concept" concept which describe a kind of entity,
• the "Relationship" concept which describe a kind of relation between two kinds of entities and
• the "Modularity" concept which makes a model usable

Inheritance relationship and attribute concept are also often used, but these concepts are out of the scope of this paper.

So, we have shown here the importance of the modularity concepts used to represent models, meta-models and meta-meta-models. And the differences between classical layered based meta-modelling architectures and sNets architecture can be summarized in the following schemes :

Dashed arrows represented in these schemes are "instance-of" relationships between entities and their meta-entity. These relationships can't be represented in classical architectures, but implicitly exists. In sNets formalism, these relationships must be represented and are called "meta" relationships.

There is no need to redefine in each new meta-model a "package" concept because this concept is defined in the sNet core (called commonSem) which is extended by all meta-models.

Using the sNets formalism, meta-meta-models are also meta-models and models. And meta-models are also models. Then, every tool defined to work on a model will be able to work on a meta-model as well as on a meta-meta-model. For example, we have defined a generic browser which can be used to browse models as well as meta-models and a generic grapher which can be used to create new models as well as new meta-models.