When is a Metamodel not a metamodel?

[Paolo F Cantoni]

We are familiar with creating an MDG, particularly in this section of the website.  The MDG defines the nodes that the technology allows you to create and the edges that can connect them.  It also allows you to define how the various nodes and edges will be rendered, along with any constraints that may apply.  It further allows you to define the nature and properties of the items.  This sounds suspiciously like a metamodel, but is it?  If it’s not a metamodel, what is it then?

I’m asking for your thoughts.

We currently create our MDGs in a separate repository that contains the MDG definitions.  We then generate the MDG and apply it to the repository that holds the actual models we are developing.  As the MDG developer, I can review the diagrams (in the MDG repository) for the items and visualise how they will appear in the model repository.  But this is too difficult for the user who just wants to model and understand the rules.  “The thigh bone’s connected to the knee bone, the knee bone’s connected to the leg bone... etc.”.  So I thought we’d create the equivalent diagram to the one in the MDG, but with the «stereotype» item replaced by the generated item and the «stereotyped relationship» replaced by the generated edge and so on.  This would provide a visual view of what the MDG can do.

What kind of diagram would this be?  Could I call it a metamodel diagram?  What about the items, both nodes and edges, on the diagram?  Are they the generated items or something else?
For example,  I have «stereotype» in the MDG whose _metatype is Concept.  Concepts are represented as nodes in the model (in fact, they look suspiciously like ArchiMate Meaning items).  Do I place a Concept on the diagram, or do I place a Concept Node on the diagram?  Similarly, do I place a Composition or a Composition Edge on the diagram?

Thoughts and suggestions would be much appreciated.

Paolo

[Geert Bellekens]

Hi Paolo,

I generally have three different models (with their corresponding diagrams)

1. A conceptual metamodel. This is where we start. The metamodel is basically a class diagram. Each element is a class, each property is an attribute. Each relation an association (sometimes with aggregationkind=composite). We also do taxonomy using generaralizations. These are the requirements for the MDG developers.

2. The EA UML profile model, used to generate the MDG. This is sort-of the platform (Sparx EA) specific implementation of our conceptual metamodel. Here we decide which elements will be stereotypes, and how to implement properties and relationship constraints.

3. The metamodel poster. This is a visually pleasing representation of the metamodel that can be printed and hung on the wall as a poster. It uses the visual representations as the users see them in the model and diagrams. Usually this is not complete, but more of a summary showing the most important elements and relations.
My experience is that this works best to communicate the metamodel to the average modeller.

Next to these models/diagrams we also have guidelines documents, detailing usage and rules of each of the metamodel elements. Here we include things like naming conventions, location in the model, etc...

Geert

[Modesto Vega]

I now follow a similar approach to Geert, with possibly one exception I am still thinking about.

I typically have the following:

1) A conceptual model, using UML class diagrams, without attributes. Depending on the size of the MDG, I will use multiple diagrams.
2) A Logical model, again using UML class diagrams, with attributes. I use as many diagram as I used in the conceptual model.
3) The EA profile used to generate the profile.
4) And, often but not always, a poster leveraging the conceptual model, typically breaking down the model into, for example, aspects or layers.

I always keep all the above in the same repository or branch of the repository.

The exception I have not worked out yet, is how well the above works for an MDG based on, for example, Sparx EA implementation of ArchiMate. The main reason is that is that I don't want to get caught in reverse translation exercise.

[Paolo F Cantoni]

Thanks, guys, for your input.  Most valuable!

I think, using (mainly) Geert’s reply, that what I am building is a profile diagram.  Its intent is similar to the poster, but drawn from an individual node’s perspective (like my Neighbourhood diagrams).

The next problem is that, unlike the paper or PDF poster, I’m creating a model.  So I think I need to distinguish my Concept Node item from the Concept item.  Perhaps I could name the Concept node “«Concept»”, since it embodies the metatype?  Thoughts, other suggestions?

Paolo

[Geert Bellekens]

You could also say it's a prototype model.
You are making prototypes of the concepts to illustrate their usage.

Geert

[Paolo F Cantoni]

You could also say it’s a prototype model.
You are making prototypes of the concepts to illustrate their usage.

Geert

Good thought!  Maybe a Metatype diagram, since that’s what’s going to be on it!


Paolo