Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generating instance according to the metamodel #1

Open
Z-Rajaei opened this issue Mar 26, 2020 · 2 comments
Open

generating instance according to the metamodel #1

Z-Rajaei opened this issue Mar 26, 2020 · 2 comments

Comments

@Z-Rajaei
Copy link

Hello, I want to generate instances according to my metamodel. For example, I have a family metamodel, in which one family can have one to many members.

In my case one instance should have one family and some members. But the tool generates some family objects with some member objects.
This tool, as I found, does not care about the references and multiplicities and it just generate a random number of objects from the existing classes. Am I right?

@abelgomez
Copy link
Contributor

Hi @zr2358 . I assume you're refering that you expect a single root objet of type Family, which contains a set of Members. In EMF there's no way to specify at the metamodel level that your application expects Resources with a single root object (that's just a convention you decide in your code). That's why the generator creates several root objects.

The generator executes some heuristics to determine which are possible candidate root objects (by default, checks for non-abstract, non-interface classes that are not referenced by a containment reference).

Regarding references and multiplicities, it is quite time consuming to validate all references and multiplicities, so a compromise between efficiency and correctness has been chosen. As stated in the doc: The instantiation process is guided by a goal number of EObjects (i.e., expected size of the result instance in terms of number of elements). The generation stops once this number of elements is reached and no multiplicity constraint in the containment references is violated. So, multiplicites are checked for containment references. As far as I remember, they are also checkted for attributes. Multiplicities for cross-references are harder to respect, specially, in big models and are not actively checked during the generation. That's why the generator can produce several models per execution (-n | --number-models <models> option) and the -g | --diagnose option is available: the process may produce incorrect models, but you can check which ones are valid or not in a row.

Finally, as a solution, you can customize the code guiding the generation process (class https://github.com/atlanmod/mondo-atlzoo-benchmark/blob/master/fr.inria.atlanmod.instantiator/src/fr/inria/atlanmod/instantiator/GenericMetamodelConfig.java) to force having a single root object of type Family. It's been a long time since I checked the code, but my recommentation is you to start by the GenericMetamodelConfig#possibleRootEClasses() method to return only the EClass Family, the GenericMetamodelConfig#getResourceSizeDistribution() to control the Resource size, and the generator method SpecimenGenerator#generate() in https://github.com/atlanmod/mondo-atlzoo-benchmark/blob/master/fr.inria.atlanmod.instantiator/src/fr/obeo/emf/specimen/SpecimenGenerator.java to control the logic (if modifying the GenericMetamodelConfig is not enough).

@Z-Rajaei
Copy link
Author

Dear @abelgomez, thanks for your explanations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants