| Re: [mdt-papyrus.dev] Where is the code generator for diagram tests? |
On Wed, Apr 15, 2015 at 8:10 AM, CADAVID Juan <Juan.CADAVID@xxxxxx> wrote:
Hi all,
I have to admit, as I was way advanced in writing the transformations, that I wished I used Xtend for the whole workflow. The language features such as the powerful switch, lambda expressions and extension methods would have made it much easier and prevent many « hacks » I had to do. I’m not sure if preserving accidental order of the input collections in order to obtain a deterministic ordering at every execution would be the main reason, but I do would support porting these two transformations to Xtend.
I have to say though that I don’t see why QVTo treats UML collection properties as unordered sets. In UML.ecore, the « UML::DataType::ownedAttribute » feature is declared as ordered=true and unique=true, which means they should be treated as the OCL type OrderedSet and not just Set...
Juan
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink
Envoyé : lundi 13 avril 2015 23:33
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : Re: [mdt-papyrus.dev] Where is the code generator for diagram tests?
Hi
You're missing the point. QVTo is doing precisely what it is told to do. Process unordered elements.
You can abandon QVTo and use something that preserves accidental order.
You can modify QVTo transformations to keep recreating ordering.
Best choice: You can modify/use modified source metamodels that specify the ordered as you actually require.
Next best choice: you modify your final stage (Xtend/Java) to create a repeatable ordering.
(I find the enhanced Xtend facilities confusing and inconsistent and the tooling depressingly inferior to Java, so I only use Xtend when I need template literals for model-to-text.)
Regards
Ed WillinkOn 13/04/2015 21:09, Christian W. Damus wrote:
Thanks, Ed.
The XMI IDs are not a difficult problem; I have that in hand (though I’ll take a look at your references). The greater concern for me is the stable code ordering problem. The approach in the current tests generation prototype is a pipeline of transformations like so:
GMFGen model describing the diagram
-> UML model describing the digram
-> UTP model describing the tests
-> Java code implementing the tests
The first transformation is a QVTo mapping from GMFGen to a UML model comprising InstanceSpecifications. These are instances of UML class model of the GMFGen metamodel. Already, the contents of this UML model are randomly ordered because of the way the QVTo is formulated.
The second transformation is a QVTo mapping from these UML instance specifications to a model of test context classes and test case operations, an instance of the UML Test Profile. Again everything is randomly ordered, in part because the QVTo deliberately creates (or converts) all collections as Sets. But even when that is fixed, all of the collection properties in the model are implemented as sets by QVTo anyways, which needs an ugly and pervasive Java hack to get around.
The end result is that the last transformation, Xtend codegen templates, generates randomly ordered Java code in a different ordering every time.
Employing orderedBy(name) all over the QVTo scripts won’t help because the core problem is still that UML properties are implemented by QVTo as sets (well, most of them are). So collections will end up randomly ordered, anyways.
So, I guess what I need is either a way to tell QVTo not to implement the UML metamodel’s uniqueness/orderedness constraints in its collections and just use the ELists as they are *or* use something else than QVTo. Or I have missed something else?
Xtend does offer supra-Java facilities that are particularly useful for model-to-model transformations, such as create operations and dispatch operations which together make a pretty slick mapping capability. Java 8 is catching up with other Xtend language features, but Papyrus isn’t at Java 8 yet, either.
Thanks,
Christian
On Mon, Apr 13, 2015 at 3:48 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Christian
In principle you are asking for the output model to exhibit a characteristic that is an accidental rather than specified characteristic of the input model, and so it is only exhibited by a helpful EList implementation.
There is certainly a lot to be said for Xtend for model-to-text, but in this case I see little that Xtend offers compared to Java; indeed it seems an example where Xtend is IMHO worse than Java.
If you want to stay within OMG tooling, you can modify your QVTo to have ->sortedBy(...) at all relevant points.
Perhaps your problem is really in UML2 whose inability to stabilize xmi:ids is very unhelpful for e.g. Ecore2UML.
For the UML-derived OCL pivot model I ensure that all xmi:ids are derived algorithmically ensuring that they are stable, reproducible and even predictable for references to future models. This uses Java Switch-based code.
See org.eclipse.ocl.pivot.uml.internal.utilities.UMLXMIID which suits my purposes. It is not necessarily suitable for arbitrary usage.
Regards
Ed WillinkOn 13/04/2015 20:19, Christian W. Damus wrote:
Hi,
In my attempts to modify the QVTo transformations in the test generation framework to output model elements in a consistent order in each execution (to fix the problem of UTP models being randomly ordered and, hence, the generated code), I have so far concluded that QVTo is the wrong transformation language. I think it would be necessary to override every access and modification of list-valued properties of UML model elements with Java black-box operations, which rather defeats the purpose of a high-level language like QVTo.
The problem is that QVTo dogmatically applies the uniqueness and ordering attributes of properties in the UML metamodel. Consequently, most collections end up being implemented by QVTo as randomly-ordered Sets. The only way to work around that is to access these collections via Java black-box operations that just operate directly on the collections as Lists (QVTo Sequences).
Doing this consistently would pretty much rewrite all of our QVTo transformations, which then begs the question Why wouldn’t I just rewrite them all in Xtend, which in addition to treating collection properties natively as the Lists that they are, provides more seamless integration with Java (including debugging and searching)?
Thoughts? Would any of the QVTo experts on the Papyrus team know what I’m missing (if, indeed, I’m missing anything)?
Thanks,
Christian
On Mon, Apr 13, 2015 at 8:42 AM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Benoit,
I see now. I agree that some kind of “generated with version x.y.z of the framework” notation somewhere in the output would be valuable. With EMF it’s perhaps implicit in the settings of the GenModel (which target EMF version does it specify) and the git commit timestamp. But something more explicit would not be difficult.
My latest revision of the Gerrit change adds the first (most simple) tests for canonical synchronization, as demonstrated here. Up next I plan to tackle the problem of regeneration utterly changing very file, which is terrible for diffs and SCM. As I see it there are two basic issues:
- UML models are generated with new random UUIDs each time. These need to be replaced by stable, predictable unique IDs, much as UML2 does in the “Convert to Metamodel” action
- the UTP test model is generated in a random order because the QVTo transformations use sets for every collection. Consequently, the order in which every particle of code is generated changes each time
I’ll see how far I get with this today.
Thanks,
Christian
On Wed, Apr 8, 2015 at 10:46 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:
Hi Christian,
As you already know J
I’m strongly advocating the fact to remove all generated code from the repository
The generated code should always be up to date with the model and not mixed with some handcoded code.
BUT the generated test is here to check any regression
Obviously if your generated tests are up to date with your model your tests should always pass
ð That’s why the generation of the tests should be done manually (still bind to the build tool J )
For example :
- I made a very simple generator to generate a junit test class for element type (I hope to share it when the work is done)
(My main concern is to avoid any id regression since ids can be specialized (so are part of our api J) )
- Let’s say that we get the last official version for SysML 1.4, I will generate the new elementtype file
- if the tests are generated at runtime then they will use the new ids as input and pass
- if the tests are manually generated, they will failed on a regression (I will have to manually call the build tool for updating them or patch my regression )
ð That’s why generated test should not be managed exactly like generated code (It may have some exception)
About the “versionstamp”, it is just a way to know the version of the tool that generated the code
By experience there are some times when you can’t regenerate the files
but much much worse you also don’t know what version or even tool that was used.
ð The best way would be to use a file without semantic meaning (my recommendation use package-info.java)
Regards,
Benoit
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : mercredi 8 avril 2015 15:37
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Where is the code generator for diagram tests?
Hi, Benoit, Juan,
Thanks for the follow-up. See some more responses to both of your replies, in-line below.
Cheers,
Christian
On Wednesday, Apr 8, 2015 at 05:11, CADAVID Juan <juan.cadavid@xxxxxx>, wrote:
Hi Christian, Benoit,
Thanks for updating the contribution. I’m having a hard time finding time to work on the test generator, but I see you were able to start extending the transformations, and I will follow up and your suggested changes.
I certainly don’t mind continuing to work on this to get it up-to-date with the current Mars codebase. I have essentially planned this week to do that. It’s a learning opportunity for me. :-)
Initially, I wanted to submit two patches as Benoit suggested, but I had some mutual interdependencies which did not allow to isolate one from the other (e.g. I put the generation launcher in each diagramXX.tests plugin, thus creating a depencency to oep.test.framework). I’ll fix that as soon as I can.
Again, I can see about the feasibility of splitting this into separate codegen/framework and generated-code patches once I have the current patch working. I don’t want to derail your schedule, and I’m already into it.
Juan
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de MAGGI Benoit
Envoyé : mercredi 8 avril 2015 08:24
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] Where is the code generator for diagram tests?
Hi Christian,
I’m not aware of all the details, but yes it seems that this patch is pushing new tests for most of the diagrams.
It may be a good idea to split the patch to separate :
- the generator (+framework)
- and the generated tests (for each diagrams)
Agreed.
If we want to maintain this generator, we should also add a “version time stamped information”
in the one (many) of generated files since the generated test don’t follow the same lifecycle as standard generated code.
Could you explain in more detail what you mean by this? I’m not familiar with a version timestamp pattern in code generation, and I don’t know what lifecycle you refer to.
Thanks!
Regards,
Benoit
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : mardi 7 avril 2015 16:50
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Where is the code generator for diagram tests?
Thanks, Benoit.
It appears that this generates an entirely new suite of tests, correct? I’ll take a look at extending this framework to support my needs, which are a bit peculiar because my test cases are driven by edits in the semantic model, not by edits in the diagram.
I expect I’ll be returning to the mailing list for a good deal of help in the next while … :-)
Christian
On Tue, Apr 7, 2015 at 2:17 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:
Hi Christian,
I believe the generator is Gerrit (here [1]) waiting for a review.
Regards,
Benoit Maggi
[1] : https://git.eclipse.org/r/#/c/38587/
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : lundi 6 avril 2015 16:59
À : Papyrus Project list
Objet : [mdt-papyrus.dev] Where is the code generator for diagram tests?
Hi, Team,
According to the developer guide on the wiki [1], there is a diagram tests generation framework. It is also referenced in the headers of some source files as the “Papyrus Test Framework”. Certainly, many of the tests appear to be generated.
Where is the code generator? I don’t find the QVTo transformations alluded to by the wiki documentation. I don’t see the UML Testing Profile in the repository, nor any MWE workflows or launch configurations that would run test generation.
I ask because I plan to add diagram synchronization (canonical-edit-policy) tests to each diagram’s test bundle, and I thought it would make sense to investigate the possibility of including some scaffolding at least in the test generator. Perhaps these tests were generated once by something that isn’t in the repository and have ever since been maintained “by hand”?
Thanks,
Christian
_______________________________________________mdt-papyrus.dev mailing listmdt-papyrus.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4328/9529 - Release Date: 04/13/15
_______________________________________________mdt-papyrus.dev mailing listmdt-papyrus.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4328/9529 - Release Date: 04/13/15