Root CUIP Metalevel

Posts tagged “metamodel”.

Metalevels & Meta-metalevels

It seems like a tongue twister, and sometimes it is. Modeling and metamodeling is always a topic subject to high probability of misinterpretation. At the end, the concepts involved has subtle differences, but talking about then in different levels depending on the properties we want to stress.

My friend Peter Bell posted some time ago, a nice introductory article to models, metamodels and meta-metamodels.

If you have some basic background on databases, the examples Peter provides, will be useful to understand it all.

On the contrary, I usually preffer to explain it starting from the top and then going downto the hill. But I have to recognize than the reverse (as explained by Peter) is probably easy to follow for newcomers.

Now my version:

Take the following concepts: entity, attribute and relation. These are more than enough to create your basic meta-meta-model. With this primitive concepts you can built everything from scratch in every model!

  • OMG / MOF call this level M3.
  • When instantiating these M3 concepts, you can build M2 models and create meta-models for UML class diagrams, or state-machines. For example, UML class can be described as an entity with an attribute called Name, etc.
  • Instantiating M2, it allows you to create M1 models: tipically your business problem to deal with invoices (class Invoice) and customers (class Customer) and its corresponding association relationships.
  • Finally, when instantiating M1 models, you are finally creating living objects in an M0 world (let’s call it: The Reality). For example, customer=ACME and invoice=INV0003 are living objects at your aplication run-time.

Funny and weird, isn’t it. It’s like building aztec pyramids but with a top-down approach.

This layered approach to modeling based in abstraction and instanciation are crucial to undestand MOF, or any meta-modeling tool you ever use.

  • M3 (meta-meta-models) used to be hard-wired in metamodeling tools like MetaEdit, EMT, or MS DSL Tools/Corona.
  • M2 defines the rules for modeling (meta-modeling). A typical metamodel is the UML metamodel hard-wired in each UML tool you use. If your are changing an M1 model, you are creating a new language, in a literal sense. Sample the UML class concept.
  • M1 are each of the instances or models you create with tools like UML. Sample: a class named Customer.
  • An M0 sample would be the object ACME persisted as a row in a table and representing a customer in runtime in one particular software, for example.

Frequently people ask: why we stop at M3? It’s is not possible to have M4? An upper model to M3?

Well, the easy answer to this is No.

However the long response is: Can you find a more simple primitive concepts of entity, attribute & relation in a more abstract way and still be capable to derive/express the same concepts? If this is possible and convenient for your domain, then you just have invented your M4 model.

At the end, you start defining some primitive concepts like axioms: they can not be simplified or divided in simpler parts and ones axioms can not deriver others.

Note that you can use as many levels as needed, but you need a root level containing the axioms to start from and a M0 to set an arbitrary reference for the reality. To my preferences, I would have started to name it in the reverse order, M0 for the axioms, and M3 for reality.

The core metamodeling concepts in MOF, EMF, Meta-Edit and MS models are basically the same if you take a look: entities or core-classes, attributes or properties and relations.

From these primitives, it is easy and convenient to build any syntactic construction needed for the lower levels.

On the contrary, how to incorporate the emerging semantics in each new level is still a topic for strong discussion. But this is another interesting open topic for another post…

Long life to meta-meta-modeling!