One (virtual) model repository to rule them all

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

In the last few days, I´ve learned about a new model repository (in a broad sense, remember “Everything is a model”): MDEForge , attended a demo of the new functionalities in ReMODD and learnt about Morse (older) model-aware repository. Remember that not so long ago I also launched a (modest) OCL-focused repository. The Free Models initiative keeps an index of all these initiatives (though there are still some more out there like oomodels) . And to those, you need to add (semi)private repositories owned by many commercial tool vendors (e.g. GenMyUML for instance)

So, plenty of research initiatives, each with their own interesting specificities (e.g. MDEforge aims at not only storing the models but executing them even suggesting possible transformations to the user, ReMODD allows you to upload images and pdfs representing models to avoid restricting submissions to specific formats, my OCL repository is a GitHub project to let users contribute without having to register or learn yet another interface) but one common problem. They are all mostly empty.

And this is not going to change in the near future wich such a fragmented market. And I don’t foresee them converging either (for a variety of reasons, ranging from personal to technical). This hampers a lot their appeal to other researchers. As of today, if I want to evaluate my modeling tool over a representative set of models I may need to interact with several repository interfaces (and a few of them do not have option to access all models so I’d need to manually donwload them one by one). Just to give an example, this is one of the biggest problem we have with EMFtoCSP : we can’t find good models to prove how good (or bad) EMFtoCSP behave with industrial models and, even less, get a set of models that could be used as the basis for comparing EMFtoCSP against similar verification tools.

IMHO, the only viable solution is to federate the different approaches in a virtual model repository that acts as a single entry point for any user that wants to browse/query (and maybe even contribute to) the repository. This would allow each individual repository to exist on their own while at the same time enable end-users to query all of them at the same time. Technically, I think it´s easier than it seems. It would be “just” a matter of defining a common API that, each individual repository interested in becoming part of the federation, should implement. The virtual repository would focus on giving a transparent access to all members of the federation, not try to replace them.

We did some experimentation on this topic some time ago while working on MoScript – a textual DSL for querying and manipulating model repositories. MoScript used a megamodel to abstract from the specificities of individual repositories and give the possibility to define abstract queries on them. For instance, with MoScript, you could use this query to retrieve all metamodels with less than 20 elements:

 

1

2

Metamodel::allInstances()

−>select(mm | mm.allContentInstancesOf(‘EClass’)->size() < 20)

 

and this one to get all models of type Java and apply to each of them a predefined java2dNet transformation

 

 

1

2

3

4

5

6

7

 

 

let javaModels : Collection(Model) = Model::allInstances()

−>select(m | m.conformsTo.kind = ‘Java’) in

 

let java2dNet : Transformation = Transformation::allInstances()

−>any(t | t.identifier = ’java2dNet’) in

javaModels->collect(jm | java2dNet.applyTo(Sequence{jm}))

Hope to finally see some day (before I retire I mean) a useful model repository. This virtual federation is my pragmatic proposal to this open challenge. What’s yours?

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. Rafael Chaves
    • Jordi Cabot
  2. Pieter Van Gorp
    • Jordi Cabot
  3. Regina Hebir
  4. Pieter Van Gorp
  5. Jiri Dvorak

Reply

Your email address will not be published. Required fields are marked *